| Age | Commit message (Collapse) | Author | Lines |
|---|
|
There weren't any conflicts in this merge.
|
|
With this commit, a short line telling that Maneage has tutorials
showing the workflow in a practical way has been added. Because of we
are near to the limit of words, I have added just a very short line. The
sentence does not specify any file name since the tutorial(s) is not
included (it will be in a near future).
|
|
With this commit, I have included a small line to recognize Julia
Aguilar-Cabello as the designer of the Maneage's logo.
|
|
|
|
The contents until two commits ago when I started to summarize the paper
are now in a new and shorter format: previously the discussion started on
page 25, but now it starts on page 17. It is still a little longer than
8000 words, but not as significantly as before. I will add the discussion
and also try to summarize it futher before submission.
|
|
As described in the previous commit, we had to shorten the paper to roughly
8000 words (which is significant decrease!). With this commit, I am
committing the current version of the summarized paper, where the
introduction, defintions and principles have now been summarized. I am now
summarizing the rest (describing Maneage and the discussion).
|
|
We just recently recognied that the final paper should not be longer than
8000 words. The easiest way was just to start a new `paper.tex' and bring
in parts from the original/long version. We can use all the hard work that
went into writing the long paper later (possibly in a manual for
Maneage). So I don't want to suddenly distroy its history at this point.
To let Git know about renaming the original `paper.tex' to
`tex/src/paper-long.tex', I am making this commit. This commit doesn't have
any `paper.tex' and only records the fact that it has been renamed. In the
next commit, I'll re-create `paper.tex' which will host the short/final
version. But thanks to this commit, if we later make any changes to long
version, Git will know that it was originally the main `paper.tex'.
|
|
Thank you very much guys :-).
|
|
I tried to get all the words I knew. Some may be correct in different
conventions. It definitely needs a second or third review for spell
checking.
Suggested some additional formatting, including but not limited to
using the LaTeX \textsuperscript{} command for stating dates.
Also, some unfamiliar rare words that finished with `-able` or
`-ability` may need to be changed. Finding better alternatives to
better simplify and ease the `readabiliy` ;-) of the paper - I see
it's hard not to use them actually. It has got me wondering what
better alternatives are available? We'll find out.
|
|
to shorten some sentences, fix some spelling/typos, and further
simplify some parts.
I can see that there are some spelling errors in the rest of the paper.
They will be taken care of in the next commit.
|
|
There was only a small conflict in the abstract with Zahra's corrections
and that has been fixed.
|
|
A parenthesis was added to the abstract to hightlight the importance of
data lineage for reproducibility. Also, the definitions that Zahra had
given for reproducibility were added as comments above the part on defining
reproducibility. We'll later decide how to blend them in, if possible.
|
|
With this commit, I have corrected several minor typos in Section 2
(Definitions). I have also put a couple of notes for modify or ignore
some phrases.
|
|
With this commit, minor typos have been corrected in the Introduction
section. The majority of them are just small corrections, others are in
order to not use contractions ("did not" instead of "didn't" and so on).
Other modifications have been added with the aim of remove some small
portion of the phrases to make it more focused.
|
|
With this commit, I have tried to make the Abstract a bit shorter. I
think it was too long considering that there are plenty of space in the
paper to describe some of the points that were noticed in the abstract.
The main point is just to try to be atractive to the reader being
focused to the main points. In any case I think there are room for
improving it. The keywords have also been sorted alphabetically.
|
|
With this commit, I have added my name as co-author of the paper. Since
my affiliation is the same as Mohammad's affiliations, I did not have to
add any additional line for that.
|
|
Because one of the most important properties of Manaege is
reproducibility. I think is it better to say something about it in the
abstract, like the thing that you do in your speech.
With this commit, I noted something about it in the abstract.
|
|
I hadn't updated the abstract since first writing it. With this commit, it
has been updated to be more precise and generically interesting, focusing
more on the principles and usability. I also greatly improved the section
on publishing the workflow.
|
|
This section (of sharing a build directory between multiple members of the
project) is also a good features of Maneage.
|
|
The figure was greatly improved, becoming much more clear and descriptive
of some of the main advantages of having version control in a complete
project like Maneage.
|
|
With the main structure of Maneage explained, I have started to explain how
a new project is created, along with a schematic diagram that shows two
scenarios of how Git can help with project management.
|
|
Until now, the introduction had repeated several things and also had a
relatively long list of things to add in its end. Also, it was highly
focused to scientific papers.
With this commit, I effectively re-wrote it, with the starting paragraphs
becoming more industry-friendly, while also focusing on the scientific
cases. Many of the repetative parts were removed and the listed items in
the end were put into the text in a much better context.
Also, now that the name of the system involves "lineage" (and a lot of
focus is put on it in the start) the terms data provenance and lineage were
defined in the definition section.
Some other intersting points that I encountered during the research on
definitions were added to the discussion and final lists, and the DOI of
one reference paper was corrected.
|
|
With this commit a description of these two important parts have been added
to the project, along with several figures showing various parts of the
files that are discussed. I also done some other restructuring of the
figures and files to make things fit better into the the description of the
paper.
|
|
Until now, I was mistakenly multiplying the fraction of papers in that
journal. This is corrected with this commit.
|
|
In order to make the description more clear and readable, the rules in the
demonstrated Makefile (and their links to the data lineage plot) were made
more clear.
|
|
Until now, there was no explanation on an actual analysis phase, therefore
with this commit an example scenario with a readable Makefile is included.
The Data lineage graph was also simplified to both be more readable, and
also to correspond to this new explanation and subMakefile.
Some random edits/typos were also corrected and some references added for
discussion.
|
|
This was done just to get going with describing the analysis process.
|
|
The text was slightly improved/edited and I also recently came up to the
Menke et al. 2020 (DOI:10.1101/2020.01.15.908111) which also has some good
datasets we can use as a demonstration here.
|
|
While reading over the already written parts (and hopefully complete the
paper), they were edited/corrected to be more clear.
|
|
Some edits were made after rereading of some parts.
|
|
With this commit, the general outline of the analysis phase is given, as
well as a description of the LaTeX macros and their relation to the paper
and thier verification.
Also, the data-lineage figure was updated to have references.tex also and
some resizing of the folders in file-architecture to be more clear.
|
|
In the last few days I have been writing these two sections in the middle
of other work. But I am making this commit because it has already become a
lot! I am now going onto the description of `./project make'.
|
|
Until now the file architecture plot at the directories ontop of the
top-level files. This made it hard to visually identify the top-level
files. They are not placed ontop of the sub-directories and some space is
added to highlight the files in the top-level directory and those in the
subdirectories.
Two other changes were made:
- The symbolic links created in the top source directory are also shown.
- The coding of this figure was made much more elegant by defining a
PGFPlots node class and just changing the things that are direrent
between each directory.
|
|
It was a little hard to describe the file structure so instead of using a
standard listing as most papers do, I thought of showing the file and
directory structure as boxes within each other (modeled on the Gnome
disk-utility).
Some other polishing was done throughout the paper also.
|
|
Until now, I was writing the paper without the template. But we will soon
be adding a tutorial to the template, and I thought it will be good to have
an example demonstration here too. So I just brought the hole project into
the template structure, allowing us to add the template analysis later when
its ready, and also allowing us to easily reproduce this paper ofcourse
(without having to worry about the host's TeXLive installation.
|
|
The unnecessary parts were removed and the project now runs.
|
|
Now that its 2020, its necessary to include this year in the copyright
statements.
|
|
Since we got the RDA Adoption grant, it was necessary to add it in the
acknowledgements.
|
|
Until now, the paper's title and author information were set it
`tex/src/preamble-header.tex'. But they are actually shown in the final PDF
paper and a much better place to keep them is the top-level `paper.tex'.
With this commit, the setting of the title and author names has been moved
to `paper.tex', just after importing all the preambles. However, the basic
package importation and low-level settings are still set in
`tex/src/preamble-header.tex', because they are relatively low-level.
This task was suggested by Deepak (Indian Institute of Astrophysics).
|
|
After the checklist was applied in the 5th Indo-French Astronomy School, we
found some cases in the checklist that were extra (and thus had to be
removed), or were needed (and thus were added).
Also the non-necessary steps for a first commit were moved to a
separate/new section in the checklist for the people to add after doing
their first commit.
Also, the software part of the paper was moved to an appendix.
|
|
Until now, the `tex/build' symbolic link was put in the clone/source tree
when the build-directory's `tex' directory was being built. Thanks to
Roberto Baena, we just found a bug because of this behavior: when a second
group member is trying to build the pipeline, since the build directory's
`tex' directory already exists, no `tex/build' will be put in their
clone/source directory. As a result, the PDF building will crash.
To fix this (and keep things organized), the two `tex/build' and `tex/tikz'
links (to the build directory) are now built in the configure step while it
is building all the top-level directories. They are no longer built within
the Makefiles.
Also, a comment was added on top of every directory built during the
configuration phase to be clear.
This fixes bug #56362.
|
|
Until now, the software building and analysis steps of the pipeline were
intertwined. However, these steps (of how to build a software, and how to
use it) are logically completely independent.
Therefore with this commit, the pipeline now has a new architecture
(particularly in the `reproduce' directory) to emphasize this distinction:
The `reproduce' directory now has the two `software' and `analysis'
subdirectories and the respective parts of the previous architecture have
been broken up between these two based on their function. There is also no
more `src' directory. The `config' directory for software and analysis is
now mixed with the language-specific directories.
Also, some of the software versions were also updated after some checks
with their webpages.
This new architecture will allow much more focused work on each part of the
pipeline (to install the software and to run them for an analysis).
|
|
All occurances of "pipeline" have been chanaged to "project" or "template"
withint the text (comments, READMEs, and comments) of the template. The
main template branch is now also named `template'.
This was all because `pipeline' is too generic and couldn't be
distinguished from the base, and customized project.
|
|
Until now, the files where the people were meant to change didn't have a
proper copyright notice (for example `Copyright (C) YOUR NAME.'). This was
wrong because the license does not convey copyright ownership. So the name
of the file's original author must always be included and when people
modify it (and add their own copyright-able modifications).
With this commit, the file's original author (and email) are added to the
copyright notice and when more than one person modified a file, both names
have their individual copyright notice.
Based on this, the description for adding a copyright notice in
`README-hacking.md' has also been modified.
|
|
With this commit, we are applying the new style of citing software within
the build rule of Gnuastro.
|
|
Until now, management of the software names and versions in the paper was
done manually (a macro had to be defined in `initialize.mk', then used in
`paper.tex', so they had to be manually set in two places). Managing this
was not easy.
To fix this, with this commit, each software building rule's target is a
text file that contains its human-readable name and its version. In the
end, the configure script sorts them by their name and writes them into a
LaTeX input file that we can easily import as a file into the main paper.
|
|
Until now, these versions were written in each run. This was mainly
inherited from the old days of the pipeline, where we didn't know the
software on the host. But now that we have almost everything under control,
we can just write these LaTeX macros at the end of the configure script and
make `initialize.mk' simpler and also (very slightly!) speed-up/simplify
the processing.
|
|
We were developing the build of Numpy and Scipy on Mac in a parallel thread
and things seems to be working relatively nice now. There were only two
problems:
1) GCC still has some random building issues on Mac.
2) ATLAS shared libraries can't be built on Mac (so we used OpenBLAS to
build Numpy and Scipy on both Mac and GNU/Linux).
But for now, none of these problems are critical. So, we can progress in
one branch.
There were only very minor conflicts in the merge.
|
|
After doing a systematic search for files without a copyright notice, a few
more were found that didn't have a notice. So a notice was added for them.
I used this Bash command to find the files:
for f in $(find ./ -type f); do \
if [[ $f != *.git* ]]; then \
n=$(grep -i copyright $f | wc -l); \
echo "$n $f"; \
fi; \
done | awk '$1==0'
|
|
In order to be more clear, a copyright statement was added to all the LaTeX
and README files.
|
