I am happy to say that the two Gnuastro GSoC 2021 projects are now on OpenAstronomy and you can apply :-).

Hi Amey,

The GNU project was not selected this year as an org for GSoC'21 :(

But if you still want to contribute, you can see the task and bugs and start with any simpler ones and make your way through the codebase. We have a dedicated manual (https://www.gnu.org/savannah-checkouts/gnu/gnuastro/manual/gnuastro.pdf) that can help you to get started and also has a Library section with all the High-level library defined.

The codebase is heavily commented so it can be easy to understand as you go through it. Please reach out if you have any further queries. Thanks for your interest :)

Hi Pedram,

Have you had a look at the Known-issues section? There are some solutions in there for similar problems regarding configuration, compilation and tests. :-)

comment #3 and comment #4

I guess the command execution order in gnuastro manual is wrong. It looks like one has to install the CFITSIO first and call the testprogram after that. Notably, this is how I tried it and it worked out just fine:

$ tar xf cfitsio_latest.tar.gz
$ cd cfitsio-X.XX                   # Replace X.XX with version
$ ./configure --prefix=/usr/local --enable-sse2 --enable-reentrant
$ make
$ make utils # just to make sure everything is there
$ rm cookbook fitscopy imcopy smem speed testprog # so it won't install extra stuff
$ sudo make install # install first
$ make utils # produce the test files, etc again
$ ./testprog > testprog.lis
$ diff testprog.lis testprog.out    # Should have no output
$ cmp testprog.fit testprog.std     # Should have no output

Hi Apoorva,

It's great to know that you're interested in contributing to GNU Astro. The first thing you should do is to play with the software a bit and get a basic gist of it. I'll recommend you to go through the GNU Astro manual here. It has sections dedicated to installing and awesome tutorials that you can follow. If there is any problem, feel free to reach out:-)

Also, have a look at comment #14 where Mohammad has explained the various steps to help you get started.

Here is my first blog for the GSoC'20. I report my progress and the tasks done here until the first evaluation.

https://sachinkumarsingh092.github.io/blog/gsoc-post1

Since a few of you asked about suggestions on a good proposal, I thought of posting a general comment here.

To start with, let me say that this it the first time I am mentoring in GSoC, and that I have no experience as a student before this. So please review other resources is well, in particular the GSoC student guide.

The first point is that you don't have to focus on a single task/bug here on Savannah! At a high-level they are independent, but as go to a lower-level, they have many things in common. You can thus can include multiple tasks in your proposal. But don't just choose a random list, or just list them. Build the body of your proposal around the common lower-level theme of the tasks you want to do, then cite the tasks.

The most important thing is that you don't need to get into too much technical detail of the code in the proposal. Those of you who have already committed code in the master branch (or are waiting for the copyright forms to complete so it be merged) can just point to your commits in the master branch and describe your experience in doing that. Use this to show that you understand the code-base of Gnuastro and that you know what you are talking about ;-)!

Please consider that the referee(s) won't have more than a few minutes to read your proposal, if you get too technical, you will loose him/her: since s/he doesn't have time to understand what you are trying to say.

So focus on 1) a good introduction to highlight the importance of your project for the astronomical community (I think in the task descriptions there are enough links to places you can cite). 2) show that you know the code structure and workflow of Gnuastro, and that you have the technical abilities to do the task. 3) Describe (generally) how you intend to solve the problem without getting too much into details (while showing that you know what you are talking about).

I hope this helps ;-).

Hi! The GNUAstro project sounds really cool to me! Always had a kind of fascination with astronomy and space since I was in school.

I may not be able to be a part of the GSoC since I'm trying to take part in another project, but this seems like a project that I would like to contribute on for the sake of it.
I've the read suggestions below for setting up and playing around with GNUAstro to get a good feel for it. That's definitely what I'll be doing.

Hoping I can make some good contributions to this project. I'll keep checking around this page.
Thank you, and have a nice day. :)

I am interested in working on it but since I am unable to build GNUAstro from source, how should I begin work on it ?

madhav_bansal, as I asked before, please keep this thread only for general GSoC discussions. Please open a bug/task report for technical discussions on a specific issue ;-).

As a fast answer, I'll look into the "pstools" issue, thanks for bringing it up (it may have been a recent update in TexLive). About the error message, it clearly says that you are missing the GNU Texinfo package or ut can't find it. Please try to reinstall it and if the lroblem persists, open a bug so we can have a more detailed discussion without crowding this GSoC thread!

To madhav_bansal (Comment #22), Can you please post more details on the problem with `tlmgr' as a Bug? You can do this by hovering over the "Bug" item above and selecting "Submit new".

I have downloaded the version-controlled source but having problem in downloading the dependencies of bootstrapping, specifically the command shown in the documentation  for installing the tex packages
command:-
tlmgr install epsf jknapltx caption biblatex biber iftex \
                etoolbox logreq xstring xkeyval pgf ms     \
                xcolor pgfplots times rsfs pstools epspdf

This is Great! It will be very useful for the Julia API project. Thanks a lot Mose.

Indeed, that would be great Mose ;-)! I also saw all the bugs you posted about cross compiling and will look into them. Until now, I have just use Debian's build farm for checking other architectures.

Hi, thanks for your interest ;-). A Julia API for the Gnuastro library will indeed be very useful, its great you are interested in contributing in this project.

About the bootstrapping problem, it may be better to post it as a "Bug". Now that you are a member on Savannah, you can just hover your mouse over the "Bugs" menu on top of this page, and click on "Submit New" to post the bug and describe the problem.

This will help keep this list only on the GSoC discussions ;-).

RECOMMENDED STEPS TO START DEVELOPING IN GNUASTRO

This is for those interested in participating in Gnuastro's development. The basic point is that you should first install and run the programs to get a feeling of their over-all purpose and usage, then start getting your hands dirty into the coding. The following list should be a rough guide on how to do this.

1. Install the dependencies. In particular, if you use the most common GNU/Linux operating systems, to start with, we recommend using your package manager. Later, when you get more advanced, you can install them from source also.
2. Install the latest Gnuastro from the officially released tarball and install it as described in the Quick start.
3. There is a full chapter on tutorials, if you have time go through all of them, if not, the general tutorial should be enough. It is a little long, but shouldn't take more than three or four hours. You don't necessarily have to understand the science behind the steps, but try to open the images (inputs and outputs). This tutorial touches upon most Gnuastro programs will give you a very good feeling of it (and thus help you develop good ideas to write in the GSoC proposal.
4. Having done the tutorial, you may have your own ideas on what to improve, or you can have a look at the list of bugs or tasks. Some more easier tasks are task #15317, task #15138, task #15136, task #15109, task #15053, task #14986, task #14908, task #14760, task #14643, task #14419, task #14409, task #14364. If they aren't already taken, you can post a comment on the task and start focusing on it.
5. You are now ready to start developing. But you will need the version controlled source, which needs to be bootstrapped. And bootstrapping has its own dependencies. So install the bootstrapping dependencies, then follow the bootstrapping guide to prepare the raw source for building/developing. After bootstrapping, you can configure and install Gnuastro's version controlled source just like the tarball.
6. Depending on the task/bug that you have selected to work on, please read the description of that particular program. For example if the bug/task is related to the Crop program, read the Crop section of the manual. This will give you an over-all feeling of the overall working style of the program and help guide you mentally when you are reading the source.
7. Read the Developing chapter of the Gnuastro manual. Please read this section carefully because it will really help you get a smooth start on the source code and our style. In particular the Program source section describes the common structure of files and programming structure of the programs. Don't forget to read the other sections of this chapter too ;-)!
8. Build you own fork of Gnuastro (as described in the Forking tutorial.
9. If you are fixing a bug, please try to reproduce it.
10. Go into the source of the program you want to work on, and start reading the code from `main.c' (which has the starting `main()' function). Follow the functions and comments until the end of the program (beware that some programs can be large and complex, you can usually tell this by the number of files in its source directory).
11. Once you have a nice mental image of the program, you are ready to start working on your selected bug/task.
12. Please don't hesitate to ask any GSoC (general) question here, but if your discussion is about a certain task/bug, please don't post it here, use the bug/task's own page.

Thanks for continuing the discussion on task #15109 Sachin. I just pulled your clone will have a closer look later.

I'll try to give more detailed feedback on that particular task later, since I am busy now. But before that, let me just make some general notes which I am putting on the GSoC discussion for others to also see.

Every project usually has a commit-message culture. Before making commits (and writing the commit message) its good to run `git log' and seeing the previous commits to get a sense of this "culture". Please do this in Gnuastro's source and read some previous commit messages to see what I mean.

As you see, the case of Gnuastro, it is really important to be very elaborate in the commit message. Infact there is a full section on Commit guidelines in the "Developing" chapter. The basic idea is that we want people to be able to follow the history by reading the commit messages without necessarily understanding the code. In fact, most of the discussion should go on in the commit messages, not on Savannah or GitHub or GitLab and etc, because the commit messages stay in the history, but text written here are separate.

Ofcourse, if you like to make really small commits, you can keep them like this, then when they are large enough to actually merge, you can rebase them into one commit and do a full description there. In this case I think it would also be necessary because I noticed you had committed your SSH public key into the Gnuastro history ;-). But even in this case, its good for the one-line commit message to be descriptive. I see that more than one commit is simply called "size operator", which isn't good ;-).

Another important point is that there should be no lines with empty white-space lines. I see two lines with just spaces under your commit f89757d31, the `arithmetic_size' function has two lines that only have white space characters. You don't see it on GitHub, but if you do a simple `git log' on your command-line you should see them.

My plan is to use the HDU metadata to extract the values of keywords 'NAXISn' for the required operand. If the above implementation is faulty please suggest the idea for a correct one.

Just to conclude the discussion on the workflow for developing Gnuastro.

Once you run the three commands above, you'll have a debug-ready built Gnuastro in the `build' directory of the source (which is actually a symbolic link to your RAM). With the built files in that directory, you can navigate a clean source directory.

Then you start editing the programs and adding/removing things.

After every change, you just have to run the `./tests/during-dev.sh' script. It will compile the changed parts and try running your test command, allowing you to test if you change does what you intended or not ;-).

I've read all the suggested portion of the manual, mainly tutorials and contributions, and I'm ready to dive into the codebase. I've cloned the repository and pushed a new branch to GitHub.

Task #15109 seems to be a good one to start, though I'll really appreciate if an even simpler task is suggested. With all that done, what are the files I should look into for making changes and adding features and how should I start? What are the things to be considered for the above task?

After bootstrapping many library and files(executables and binaries) will be included which are undesired when pushing the changes to the remote repository. Is there any option in `make` for cleaning those before pushing?

Also, how should I check my changes? Should I use `make` after every change or is there a smarter way?

Thanks in advance:)

This is a standard error with the shared libraries at run-time. It is explained in the known issues section of the Gnuastro manual (it can also happen to the build of Gnuastro). See the part where we export LD_LIBRARY_PATH. that should fix this problem   


Generally having a good to understandong of the various "PATH"s and their relations with libraries and programs is very helpful and there aren't too many good resources on them. So I tried to explain them in the Gnuastro manual: please read the Installation directory and Review of library fundamentals (and its sub-sections) parts of the Gnuastro manual carefully to hopefully never have such problems in the future (for any program/library).

If you just want to run Gnuastro, the officially released tarball may be the easiest solution. If you use the common GNU/Linux distributions, the commands to install the dependencies can be found in the manual.

Since its better to first play with a programs (to get a good feeling of the whole package), I recommend starting with the officially released tarball. In the manual there is a Tutorial chapter with some example scenarios of program usage. They don't need much astronomical knowledge and won't take much time to do (a day or two should be enough).

After going through the tutorial and running the commands and seeing the inputs/outputs, you want to start getting your hands into the underlying code. For that, you should use the version-controlled source.

But the version controlled source need to be bootstrapped, so it has some extra dependencies. They are also easy to install though ;-).

Generally, I would argue that the version controlled source is more stable (more bugs are fixed), but because it needs bootstrapping, it may be a little annoying at first (when you just want to play with the software).

Gnuastro has proposed two projects for this year's Google Summer of Code (GSoc). Please feel to ask questions here. We'll also post relevant things (like easy bugs/tasks) here for interested applicants.