| Age | Commit message (Collapse) | Author | Lines |
|---|
|
An abstract is also something most research reports will need, so a simple
macro was defined to make it easy (not too many code lines within the text
of the main body) to implement an abstract.
The title was also moved up a little to better use the extra white space at
the top of the page.
Finally, the `\highlightchanges' along with its explanation (both as
comments and within the text with examples) was added in `paper.tex' to
demonstrate how useful the `\new' and `\tonote' macros are.
|
|
Until now, we were using the `multicol' package which is mainly designed
for more than two columns. Instead, we are just passing a `twocolumn'
option to the article document class.
|
|
A few minor corrections were made in `README.md'.
|
|
The comments needed to be corrected to fit and explain the new logic (LaTeX
being run within another directory).
|
|
The comments in the preambles were made more clear and elaborate.
|
|
Having a look at the TeX source, some minor edits were made to the comments
so it is more clear.
|
|
Making plots and including references are integral parts of a scientific
paper. Therefore to demonstrate how cleanly they can be used within the
pipeline, they are now used to produce the final PDF.
To use PGFPlots a random dataset is made (using AWK's random function) and
is plotted using PGFPlots. The minimum and maximum values of the dataset
are also included in the text to further show how such calculations can go
into the macros and text.
For the references, the NoiseChisel paper was added as a reference to cite
when using this pipeline along with the MUSE UDF paper I, which uses this
pipeline for two sections. Following this discussion, citation is also
discussed in `README.md` and the NoiseChisel paper is also added as a
published work with a reproduction pipeline.
|
|
Until now, the copyright statement was left empty for the users of the
pipeline to fill. However, the files have already been created and have an
author (or contributing authors) before the user starts using the
pipeline. So the original authors of the files are added along with the
year. The user can add their own name to the existing files under the
"Contributing author" when they start and they will be the "Original
author" of the new files they create.
Several changes were also made to the TeX management:
- LaTeX is run within a `reproduce/build/tex/build' directory now. Not in
the top reproduction pipeline directory. This helps keep all the
auxiliary TeX files and directories in that directory and keep the top
reproduction pipeline directory clean. After the final PDF is built, a
copy is put in the top reproduction pipeline directory for easy viewing.
- The PGFPlots preamble was also made more useful, allowing the name of
the `.tex' file to also be the name of the final plot that is
produced. This is a GREAT feature, because without it, the TiKZ
externalization would be based on order of the plots within the
paper. But now, order is irrelevant and we can even delete the TiKZ
files within the processing workhorse-Makefiles so the plots are
definitly rebuilt on the next run.
- The paper is now in a two-column format to be more similar to published
papers.
A tip on debugging Make was added to `README.md'.
|
|
A typo (" ... followed b checklist ...") was found and corrected in
`README.md'. Also, after re-reading the paragraph, it was made slightly
more clear with some minor edits in the text.
|
|
I had made some slides for a talk here at Lyon Observatory a little over a
week ago and I thought it may be useful to add them in the `README.md' file
to help demonstrate the general concept before having to read such long
texts.
Later, we should be adding some figures to this `README.md' file to make it
more easier to understand.
|
|
The points were made more clear.
|
|
The published works using the pipeline now have a separate section for them
selves in the introduction and some of the explanation was made more clear.
|
|
`README.md' didn't contain a general description of the pipeline's design
architecture. So a few paragraphs have been added to help someone new to it
to understand it better.
|
|
The mandatory and optional (for example downloader) dependencies are now
checked at configure time so users can know what they may be missing before
the processing starts. Since its recommended to be run in parallel, it can
be hard to find what you are missing after running the pipeline. As part of
these checks, the program to use for downloading is now also set at
configure time, it is only used as a pre-defined (in `LOCAL.mk') variable
during Make's processing.
A small title was also added to discus the pipeline architecture that will
be filled in the next commit.
|
|
A few other minor corrections were applied to the text to be more clear.
|
|
Some minor edits and a spellcheck were made in the text to make it easier
to understand/read.
|
|
In the "Tips" section of `README.md', a section on version control was
added and a first tip regarding tags was added to guide (new) users on how
to effectively define and use tags. As a result, in the checklist, adding a
`v0' tag is now also suggested.
Some minor typos were also fixed.
|
|
The first comment of the top LaTeX source was confusing and is now fixed.
|
|
On some servers, `.nfs*' files are also created during the processing, so
to keep the Git repo clean (avoid an un-necessary `-dirty' prefix), we are
adding these files to the `.gitignore'.
|
|
Some editors put a copy of their input file into another file ending with
`~' (for backup). So now, the `./configure' script also cleans this file
along with the temporary file.
|
|
In some systems, the fact that `.gnuastro' and `reproduce/config/gnuastro'
are the same is not recognized by Git in `.gitignore' and so the `mmap'
files will be treated as un-commit files. So we now simply ignore all files
starting with `mmap_*' and removed the directory information before it.
|
|
While trying the pipeline on a remote server (which runs on Debian), the
configure script had an `Syntax error: "(" unexpected' error. This is
caused by the fact that in the Debian world (and its derivate OSs), the
default shell is not Bash but Dash which has much fewer features for fast
loading. It was thus necessary to start the configure script explicity with
the `/bin/bash' shebang.
|
|
Two minor typo corrections in the comments were made in Gnuastro's
configuration file to make it more clear.
|
|
As described in the commens above `MINMAPSIZE' of `LOCAL.mk.in', the amount
of memory to map to HDD/SSD or keep in RAM is a local issue and not
relevant to the pipeline's results. So it is now defined in a
`gnuastro-local.conf' file.
To keep the Makefiles clean, this file is created by the `./configure'
script. To do this cleanly, the `./configure' script was also almost fully
re-written with better functionality now.
|
|
The previous change where we had set the building of the PDF as a local
(and thus not version controlled) setting was not good, because different
commits might be made without the high-level preparations for the final PDF
(especially during the initial/testing phases of a research). Therefore, if
the runner of the pipeline is ignorant to this, they may hit some errors in
LaTeX which can be frustrating.
To have a clean reproduction, it is thus necessary to have the choice of
pdf-building under version control along with the rest of the pipeline.
|
|
Until now, Gnuastro's `mmap' files were included in the `rm' commands of
`clean*' rules two times. But by setting `clean-mmap' as a dependency of
`clean', it is now only necessary to have them in the Makefile once. This
also makes the code much more cleaner.
|
|
To help view that everything is OK and that there were no errors, an extra
blank line followed by one with `----' is added to the notice when we won't
be making a PDF. These two lines help the eye more clearly see everything
is fine (given that above it, there are MANY commands and outputs).
|
|
Managing this symbolic link as a prerequisite that may or maynot be defined
just made the code too dirty. It is almost always needed, so it is now a
super-high-level prerequisite (first dependency of the `all' target, even
before the final PDF). In this way, we can be sure it is always built and
that nothing else depends on it.
If the user doesn't want it, they can simply remove it from the top
`Makefile'.
|
|
The choice of whether or not to make a PDF is now also a local system
issue, not a general pipeline issue. So it has been put in the new
`LOCAL.mk.in' file which replaces the old `DIRECTORIES.mk.in'. All local
settings (things that when changed should not be version-controlled) should
be defined in this file.
A sanity check was added to find if `./configure' has been run before
`make' or not (using the `LOCAL.mk' file which is an output of the
configuration step). If `LOCAL.mk' doesn't exist, an error will be printed
informing the user that `./configure' needs to be run first.
The configure script also provides more clear and hopefully better
information on its purpose and what must be done.
Since `make clean', it is executed even when `./configure' hasn't been run,
it will only delete the build directory and its contents when local
configuration has been done.
A `distclean' target was also added which will first "clean" the pipeline,
then delete the `LOCAL.mk.in' file.
To allow rules like `make' to be run even if `BDIR' isn't defined
(`./configure' hasn't been run yet), a fake `BDIR' is defined in such
cases.
|
|
While going over parts of the text, some minor typos were found and
corrected.
|
|
The title "Tips on using the pipeline" was a little generic and could be
confused with people who want to reproduce the result, not the designers of
the pipeline. So it was changed to "Tips on expanding this template
(designing your pipeline)". Some minor edits were also made to its first
paragraph.
|
|
Some minor typos were found and corrected. In other cases, the text was
slightly edited to be more clear.
|
|
Recently the filename keeping TeX macros for the versions was changed from
`versions.tex' to `initialization.tex' (since it also contained the build
directory). However, it was forgotten to correct the change of name in the
`.PHONY' targets, so it was not being rebuilt every time. This is corrected
now.
|
|
`README.md' is for this pipeline, not the research project that is using
it. Therefore it might be confused with the `README' that is devoted to the
research project. So in the checklist, a point was added to delete this
file before making the first new commit.
|
|
The README file didn't match the current way to set the top-level
directories (through `./configure'), it was still the old-fashioned way of
manually finding and opening the file. The explanation is now corrected.
|
|
The basic title, short description and author section of the checklist was
moved immediately after copyright because it is more related to it. The
description of Gnuastro is now before `README' because the user will
confront Gnuastro in `README' and this will provide a good introduction on
what to do with it.
|
|
The creation of a new Git repo is now moved to the end of the checklist. It
was not in place as the third step before. Now, the user makes all the
standard changes and just before they start going into the details of their
research, they define their new repository.
|
|
The description of adding a title and authors was made slightly more clear.
|
|
The first commit didn't have an explanation on correcting the title of the
project in the final PDF or the top-level Makefile, so a pointer was added
to the list. Also, some extra dependencies were removed from `README' and
its paragraphs were scaled to the new width of 75 characters that is
defined in `.dir-locals.el' (for Emacs settings, taken from Gnuastro).
|
|
Let's start working on this pipeline independently with this first
commit. It is based on my previous experiences, but I had never made a
skeleton of a pipeline before, it was always within a working analysis.
But now that the pipeline has a separate repository for its self, we will
be able to work on it and use it as a base for future work and modify it to
make it even better. Hopefully in time (and with the help of others), it
will grow and become much more robust and useful.
|
