| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Since working on the pipeline will evolve along with the projects that use
it, it can be useful for projects to fetch updates in the pipeline. So the
checklist in `README.md' updated to explain how to do this cleanly.
|
|
Until now, because we didn't build the dependencies internally, it was
important for the pipeline to be usable with any version of Make. But
because of the new installation of dependencies (including GNU Make), that
is no longer the case. So we can safely use GNU Make and this needs to be
mentioned in `README.md'.
|
|
GNU Coreutils are basic programs that can help in the configuration of
higher-level programs. Because of that, it was a dependency of almost all
software built in `dependencies.mk'. To make things more clear, easier to
read and faster (when building in parallel), the building of Coreutils is
now moved to the `dependencies-basic.mk' rules. There, it is built
along-side Bash. Since `dependenceis-basic.mk' is run and completed before
`dependencies.mk', with this, we can be sure that Coreutils is present by
the time we want to build the higher-level programs.
Also, Zlib is now added as a dependency of Git also (it is necessary for
its build).
|
|
After going through the checklist for starting a new project based on the
pipeline, I noticed some parts that could be modified to be more
clear. They are now applied.
|
|
Until now, we were using a customized `tar.lz' tarball for Gzip. But on
systems that don't have GNU Tar, this will cause a problem (non-GNU Tar
doesn't recognize `.tar.lz'). So to keep things simple, we are using the
customized gzip in `tar.gz' format. After the internal build of GNU Tar and
Lzip, the default method of unpacking (`tar xf XXXXX.tar.XX') will work
nicely on all the standard compression algorithms and we don't have to
modify our commands based on the algorithm (nice feature of GNU Tar).
|
|
The two README files have been updated to explain the new feature of
downloading and building dependencies.
|
|
All the used software are now acknowledged in the template paper along with
their versions. This section is also mentioned in the check list, so users
don't delete it by mistake.
|
|
The version of all programs is now checked in
`reproduce/make/src/initialize.mk' and the pipeline won't complete if any
of the program versions change from those listed in
`reproduce/config/pipeline/dependency-versions.mk'.
Since the pipeline is systematically checking all program versions, we
don't need Gnuastro's `--onlyversion' option any more. So it (and all
references to it) have been removed.
|
|
To enable easy/proper reproduction of results, all the high-level
dependencies are now built within the pipeline and installed in a fixed
directory that is added to the PATH of the Makefile. This includes GNU Bash
and GNU Make, which are then used to run the pipeline.
The `./configure' script will first build Bash and Make within itself, then
it will build
All the dependencies are also built to be static. So after they are built,
changing of the system's low-level libraries (like C library) won't change
the tarballs.
Currently the C library and C compiler aren't built within the pipeline,
but we'll hopefully add them to the build process also.
With this change, we now have full control of the shell and Make that will
be used in the pipeline, so we can safely remove some of the generalities
we had before.
|
|
After a full trial of the checklist, some further minor edits were made to
make it more clear.
|
|
Some minor changes were made to be more clear.
|
|
A few minor points were corrected in README.md.
|
|
A step was added close to the top of the checklist to remind people to
check the pipeline before making any changes. Also, the `--origin' option
was removed from the `git clone' command into a separate command to rename
the origin branch. This helps in readability.
|
|
Until now, in the check list of `README.md', we were recommending to delete
the history of the pipeline and start your own history from that. But this
disables users of the pipeline to keep it up to date with new features that
are added to it.
With this commit, the main branch is now called `pipeline' (to allow users
to use `master' for their own research) and in the clone command, the
pipeline's remote is now called `pipeline-origin' (to allow the user to use
`origin' for their own remote).
|
|
While trying the checklist, I noticed that I had forgot to add my name
after the copyright year and that `reproduce/src/make/paper.mk' still had
my own name on it, the copyright notice also said `script' instead of
`Makefile' which is now corrected.
|
|
While testing the reproduction pipeline on a small project, I noticed some
parts of the checklist that were either repetative or needed to be
corrected. This is done with this commit.
|
|
In the previous commit, ` was mistakenly written as '. This was only
noticed after pushing and rendering the Markup on the webpage.
|
|
A minor edit was made in the copyright correction part of the checklist.
|
|
To be more generic (and avoid listing file names in `README.md'), a command
is now used to find the files where the name has to be added to the
copyright notice. Also, I noticed that `reproduce/src/make/paper.mk' lacked
a placeholder name/email, so one was added.
|
|
Previously we had tried to corrected the problem that `.mk' files use space
instead of TAB by setting them to be read into makefile-mode at the
start. However, for some reason, this caused a problem in reading the
maximum line length (the value of 75 wasn't read by Emacs).
So after some playing around, I found out that the problem is that the
`nil' setting (for all other files) must be defined in the end, not the
start of the basic settings and this solved this problem.
|
|
Going through the text, some further minor edits were made.
|
|
Some minor edits to the newly added parts of `README.md'.
|
|
A section was added to `README.md' for describing possible future steps
that we can take to make this pipeline even more robust. In it, I added a
first interesting thing that I think would be really exciting to add, but I
don't have time to do now.
|
|
The link to the slides describing the context was the old address (which
still works, but is just a symbolic link to the new address). It was thus
corrected to point to the proper filename.
|
|
The main online repository name has been changed to `reproducible-paper'
from `reproduction-pipeline-template'. So the cloning command in
`README.md' had to be corrected.
|
|
Some minor corrections were made regarding the output repository.
|
|
The markup for the link to the final PDF in the `README.md' file was
mistakenly written and is now corrected.
|
|
A template was made to keep the output of this pipeline as a demonstration
and it is now added to the description in `README.md'.
|
|
While doing my own project (which has grown to a processing time of about
half an hour), I felt that it would be very convenient to a record of the
outputs at major points also. But we don't want to bloat the pipeline by
commiting PDF files or large datasets that get fully changed and are just
by-products. So it occurred to me to have a separate pipeline only for
outputs and after trying it out, it indeed seemds to be a good solution.
|
|
Some futher edits were made to the paragraph describing the contents of
`README.md' for a smoother reading.
|
|
After the last commit, another minor correction is implemeneted to further
simplify the reading.
|
|
I reviewed the first few sections of `README.md' and made some small
corrections to make it easier to understand/read.
|
|
A small edit was made at the start of `README.md' to make it easier to
read.
|
|
The computer modern font that was designed by Donald Knuth and is the
default of LaTeX is indeed a very good, elegant and nice font in
print. However, most journals choose the roman fonts and thus the computer
modern font doesn't (subjectively) fit into the journal format nicely. So
the default font of this pipeline's paper now uses LaTeX's `newtx' package
for a roman style font.
Also, a set of preamble settings were added to allow headers in the pages
of the paper to make the result resemble more like a journal paper
(familiar to the eye), while also adding important information. A new
header was made for this job. This new header now also contains the title
and author settings (after all, these are also a type of header).
Finally, the LaTeX `authblk' package was used to organize authors and their
affiliations.
|
|
A few minor corrections were made in `README.md'.
|
|
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.
|
|
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 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.
|
