You can use the `tests/during-dev.sh` script to test your modifications and debugging. After making changes, build GNU Astro in a parallel `build` directory using the `developer-build` script using the --debug flag:

$ ./developer-build -d

There are more options that you can find by `--help` flag but this will get you up and running.

After that, you can use the `during-dev.sh` script to test your commands. Set the parameters in the `SET INPUT PARAMETERS` section and then run the script:

$ ./tests/during-dev.sh

For your segmentation faults, use Valgrind to debug. You can simplify this by prepending the Valgrind commands in `during-dev.sh` in this line near the bottom of `during-dev.sh`:

valgrind "$utility" $arguments $options $extraopts

Then trace the outputs back to the source of the memory leak.

You can download the TexLIve package from here. There is a quick installation instruction that you can quickly get you started. TexLive is a fairly large package but you don't need to install all of it. During the installation prompt, select the `basic` package to download and install. This will get you the minimum set of tools to write documentation easily.

I hope this helps. If you have any queries, please don't hesitate to ask :)

Its great that you have gone through the code and have a basic understanding.

In the part you have quoted, we just add a '-N' (where 'N' is a counter) to the new column names, we don't touch the column data/contents in this part.

The option to concatenate rows will be different and arguably much more easier, for example:

• You don't need to touch the column metadata like the names in the part you quoted). You can keep the metadata of the first input file (because no new columns will be added when concatenating rows).

• When we are concatenating rows, we need to work on all the columns of each file (just like how we work on all the rows when concatenating columns). So there is no need to select some of the columns.

You can define a new 'table_catrow" function for concatenation by rows. Here is a rough outline of what it can do inside:

1. Add a new '--catrowfile' option.
2. Go through all the files given to the newly added '--catrowfile' option and count how many rows each one has. The 'gal_table_info' function of 'table.h' in Gnuastro's library can do this without reading the actual table contents.
3. Add up all the rows to find how many rows the final table should have. Also make sure that all the tables have the same number of columns in the process and that each column has the same type as the respective column in the first file.
4. You now know the final number of columns (Nc) and final number of rows (Nr) in your final output table and the type of each column. Allocate Nc 'gal_data_t's as a list (each with 'Nr' elements, and the respective type).
5. Go through the list of files again, but this time read all the column data, and use 'memcpy' to copy the contents into the respective rows of our output allocated arrays, then free the read data. You can use the 'gal_pointer_increment' function in combination with 'memcpy' to not have to worry about the type of the table. There are many examples of using 'memcpy' and 'gal_pointer_increment' in Gnuastro's code which you can use as an example (you can find them with a simple 'grep -r memcpy ./' in the top Gnuastro source directory). For example there is one in 'bin/table/table.c' (in the 'table_bring_to_top' function).

I hope this helps. Later, when you get a good understanding of this, it would also be good if you can help improve the documentation to clarify the points that weren't immediately clear to you: others will have a similar problem.

Thanks! It has been merged and pushed to the main repository.

I also followed it up by a commit, polishing it a little and also enabling multiple calls to the `--catcolumn' option to add multiple tables. Please have a look at the commit message and changes to hopefully have smoother merges in the future.

I changed the task name to only focus on the rows now. If you get the chance to also implement that feature, we can close this task when its merged ;-).

Madhav, given that your copyright forms are complete, I am ready to merge, but I noticed that your commit was in parallel to another commit that I just merged into master.

To have a cleaner history, can you please pull the master branch to the most recent commit, the rebase your commit over it? Let me know when its done and I'll do the merge ;-).

done.
https://github.com/madhav-bansal/gnuastro/commits/table
We are including this option for giving user the choice to choose different HDU for -catcolumn file right?. So that INPUTFILE and --catcolum can have different HDU's?

I have inserted the option in (lib/gnuastro-internal/commonopts.h)and also check the documentation for --catcolhdu is it correct?
https://github.com/madhav-bansal/gnuastro/commits/table

please give a final check
https://github.com/madhav-bansal/gnuastro/commits/table

I think this explains the option correctly
"File whose columns to add in the main INPUTFILE(keeping number of rows fixed).
If any row selection is applied then first row selection is applied on main INPUTFILE and then concatenation is done."
please see if it correctly explains?

I have mailed again, for the copyright confirmation today.

By the way, you can check the documenation with this command:

make pdf

The generated PDF file (if TeX doesn't crash!) is saved in `doc/gnuastro.pdf'.

sorry, for making the same mistake again and again
Now I have done all the things correctly.I actually was having trouble with commit message width.
https://github.com/madhav-bansal/gnuastro/commits/table

Good, but still not enough! Please pay attention to all the other commits/codes/comments in the code. You want your code to fully blend into the program's source.

1. The commit message body description is now unreasonably short! After making the commit, please run `git log' and press SPACE (to see other messages). Then re-edit it (with `git commit --amend'), so it and repeat this until it looks like the rest.
2. In `tableparams', please look at the other comments: do you notice that the comment ending (`*/') in all the rest of the structure elements are aligned? Please do it for this line also.
3. No other name in the lists I mentioned before are FULL CAPS! Can you please correct your name to be in the standard notation (only first character to be capital).
4. Finally: the documentation has not been added.

It is a little frustrating for me to see a previously raised point is being repeated multiple times. Please pay more attention  if you are serious about this ;-).

Another (possibly) important point: I see that in the commit info, your name is "madhav-bansal". We use this name to generate the `AUTHORS' file, and also print it in the second page of the final PDF. If you are happy with "madhav-bansal" that is fine, but I just thought of bringing it up in case you want your standard name string to be put in those places ;-).

well done all the things in the table_catcolumn function itself. please give feedback.https://github.com/madhav-bansal/gnuastro/commits/table

Great! I look forward to the corrections ;-).

Its good to also add the documentation in the same commit so it can be complete.

For the GSoC proposal, once your first commit is merged into the main history of Gnuastro, I think you can make a good case that you know the source code and the workflow. But you also need to choose a useful/important project to propose to work on in Gnuastro. There are some that are suggested in the GSoC suggestion page, and of course the general task list is very complete. The Table program itself can be greatly improved and has a lot of potential, but there are many other image processing tasks.

I guess its really up to you and what you are interested in, so have a general look and if something is not taken by others, you can post a comment that you will be working on it and write your proposal.

Thanks, its getting much better ;-). I can do all of these myself (and it would take much less time for me than writing these comments), but I think it is much better to get you to a good start now. This way, your future projects in Gnuastro will be much more smoothly merged :-D.

Here are some points that occurred to me:

1. The commit message description is very good now, thanks! But length of the lines in the commit message make it very hard to read. Take a look at some previous commit messages: all the lines have roughly the same length. Also, the last one is too long (it shouldn't be more than 75 characters).
2. The name of `concat_along_row' doesn't follow the standard and is confusing: since its in a file called `table.c' it should start with `table_'. Also, since its job is concatenate columns after each other, having the name `row' can be confusing. Its good to give it a very similar name to the option.
3. In `concat_along_row', you can use the `gal_list_data_last' function (in list.h) to avoid the while loop and help in readability.
4. The function and loop braces (`{' and `}') don't follow the GNU style. Please have a look at the other functions/loops to get a good feeling ;-).
5. Since this option is about `c'olumns, maybe setting `UI_KEY_CATCOLUMN' to `C' is a better and more clear choice for `--catcolumn' compared to `f', what do you think?
6. You can just define `catcolumntable' in `concat_along_row', not in the main program structure. You can simply pass it the name of the file, and it can read into memory there. Such higher-level input files can be read outside of `ui.c'. This will also be easier later when you add row-concatenation, and also later when you allow many tables. Also, you have added the sanity check in `ui_preparations', but the check should be in `concat_along_row' (when the input table's final set of rows is found).

It looks better, thanks! But some of the points haven't been fully/correctly applied:

1. The commit message should be more elaborate! This also applies to comments: please think about others (including your future-self) is well! People read these commit messages and don't necessarily have the time review the code to see exactly what you mean by "Added an option to concatenate columns of two tables". Describe it at least in three sentences and the conditions that it can be useful. If you are not yet convinced of the importance of commit message, or comments, please see this nice word of wisdom.
2. On the output of `git log', I still see regions marked in red! Showing lines that end with white-space characters.
3. The option name is fixed, it is still identified with `UI_KEY_SECONDFILE'! This will later cause so many confusions! The name of the identifier and option must be the same.
4. The option description hasn't yet changed.

Some other points:

1. I don't see any sanity checks: what if the number of rows in the new table doesn't correspond to the number of rows in the original input? Table should abort with a descriptive error message, saying the problem (while also printing the numbers).
2. The user may first select a few of the original table's rows (to fit another table), then concatenate it. So it is best to read the table to be concatenated after all the row-selection procedures on the main table has been done (for example all the options under "Rows in output" when you run it with `--help'). For example take this scenario: `base.fits' has 100 rows, while `other.fits' has 10 rows. I run one of the operations mentioned above on `base.fits' (for example `--range'), then I want to merge it with `other.fits'. To allow this, its easier if the function to do this job is moved to the end and the other table is read and sanity-checked in the same function.
3. Also, don't forget to add documentation for this new option. You can do that in `doc/gnuastro.texi'. Its in GNU Texinfo format which is essentially TeX but with an `@' instead of a backslash. You can use the other option descriptions as a reference without going into the details of Texinfo. You don't need any complex Texinfo feature for this ;-).

No problem ;-). I am just looking at it, here are some points I am wrote as I was inspecting your commit. They are almost all cosmetic, so it won't take much time/effort to implement them. Nevertheless they are important so please implement them and keep them in mind for future commits.

1. The commit message is a single long line. Please have a look at our Commit guidelines (in the Developing chapter). Even when you want to rebase later (and write a clean commit message for many commits merged into one), it is good that you follow these guidelines, so it becomes a habit.
2. When I do a `git log' on you commit, I see that Git has marked the lines with an empty space in the end. This is generally is a very bad practice and higly discouraged (that is why even Git highlights them). Please run `git log' after doing your commit (and before pushing) to see and remove such cases in future commits. Generally most editors have modes where they automatically remove them. You can consider activating those modes.
3. You have called the new option `secondfile'. But this is too general. Why not follow the option names I suggested in a previous comment (`--catcolumns' for files that concatenate columns and `--catrows' for files that concatenate rows)? Or something like them? Such names clearly identify the job.
4. The option description starts with a space, doesn't start with a capital letter and end with a point. Please have a look at the other options and follow the same standards.
5. You may have noticed that in Gnuastro we don't use the C++ style comments (`//'). Although it is in C since C99, we have followed the basic convention of using the standard C comments (`/* */') throughout the code. Please correct them to this style.
6. In `ui_preparations', I see that you haven't followed the standard indentation (where the statement after an `if' should start after two space characters). Please have a look at other `if' statements throughout the file and follow this convention.
7. In `ui.h', you added the new `f' character for the option's short name, but didn't remove it as a free character from the list right above it. If you plan on keeping it after correcting the option names, please also remove it from that list for future options.
8. The file `doc/version.texi.tmp22936' has been commited! This seems to be a temporary file for your system/build. It shouldn't be committed into the whole history.
9. Test changes in `tests/during-dev.sh' shouldn't be committed in the end. For now (before you rebase your code into one commit) its fine, but in the end, changes in this file shouldn't be in the commit.

I am happy to hear that you have a first implementation. But I don't see any link to your forked Gnuastro (as a Git project) to see what you have done. Can you please post the Git repository link?

I encourage you to read the Developing chapter of the book. In particular the Program source and Mandatory source code files section and subsection. There, you'll see an explanation of all the basic program source files.

If you also have a look at the Gnuastro library section, you will see how you can find the definition of the macros and library functions. For example, you will see that `GAL_TYPE_STRLL' is defined in the Library data types section.

Adding new options is easy once you get use to it, but I haven't had too much time to document it yet unfortunately. In principle if you follow the functions from `main.c' you will see how the program enters `ui.c', and how it starts parsing the options.

But here is a summary of steps to add new options (I'll put this into the book later):

1. Add an entry into `args.h', just like the `column' option that you cited. The easiest case is to copy a similar option and re-set some of its parts. For two options you want to add, the `column' option is a good reference to copy.
2. Go into `ui.h' and add a `UI_KEY_*' element with the same name as your new option. This is the integer "key" that is used to identify your new option. Then use that as the second element.
3. Update the option description (4th element) to describe what the option does. This is printed with the `--help' option.
4. If you option belongs to a different "group" of options (see `--help' for the grouping), change the group key.
5. Go to `main.h' and define an element in the main program structure to host the values (in the case of the `--column' option, this is the `p->columns' element).
6. The "type" of the value is specified by the 8th element. For example if you want you option to only read a single, 32-bit floating point, you would put `GAL_TYPE_FLOAT32'.
7. If you have chosen a sufficiently similar option as a reference to copy from, you won't need to change the final set of elements. But generally, you can read about each element of this structure under in the comments of the `argp_option' structure in `bootstrapped/lib/argp.h'.
8. If the program then compiles, you can simply pass the new option and check/use its values in the program (after `ui.c') by looking into the element you defined in `main.h' (`p->columns' in the case of the `--column' option). All elements of the program's main structure get initialized to a 0 (for numbers) or NULL (for pointers). So if your new function is a pointer (like this case), one way to see if the user called your new option is to check if its NULL or not.

I hope I haven't missed anything ;-).

I am having a problem on understanding how the command line arguments are parsed in the gnuastro. I think it is done in ui.c file.
Also please tell what the file args.h is about

Also, suggest what to do with the other meta-data while concatenating the tables along  the row

This is an interesting idea, but we can make it more general: the `tcat' option in STILTS, adds rows to existing columns. Besides that, we can also have an option to add columns to existing rows.