| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Minor rewording; a reduction of about 12 words.
|
|
Minor edits - reduces about 17 words.
|
|
This commit reduces about 25 words from the 4.1 Maneage
orchestration, aka `make`, section.
|
|
This drops the word count in the introductory part of the Maneage
section by about 15 words.
|
|
Thanks to Boud's corrections, I see that the sentence can be confusing and
not convey the point I wanted to make properly, so I am clarifying it
here. The main point is that this principle complements the definition of
reproducibility, not the other principls.
|
|
These tiny language edits add 1 word in length.
|
|
Boud has contributed a lot to Maneage over the last few years and with the
last few commits he also contributed significantly to this paper, so I am
moving him to third author.
Thanks to Boud, I also remembered that even though I done the most
important parts of Maneage in Lyon, I hadn't added it as an affiliation for
myself, so I added it. Maneage became a separate project in Lyon.
Finally, I tried to decrease the length of the acknowledgments by adding
some abbreviations that were shared between various parts.
|
|
Unfortunately, adding in my name/affiliations/acknowledgments
adds about 90 words to the text. We don't really know if these
are counted by the editor in the 8000-word limit.
I changed `funded' to `funded/supported'. I only get funding from
one out of the three sources I acknowledge, but it's important to
acknowledge all three.
|
|
While looking over the PDF, a few small edits were made to be more clear.
|
|
Until now, throughout Maneage we were using the old name of "Reproducible
Paper Template". But we have finally decided to use Maneage, so to avoid
confusion, the name has been corrected in `README-hacking.md' and also in
the copyright notices.
Note also that in `README-hacking.md', the main Maneage branch is now
called `maneage', and the main Git remote has been changed to
`https://gitlab.com/maneage/project' (this is a new GitLab Group that I
have setup for all Maneage-related projects). In this repository there is
only one `maneage' branch to avoid complications with the `master' branch
of the projects using Maneage later.
|
|
The conflict was only on the list of existing tools and that was easily
corrected.
|
|
Following Boud's great corrections, I was able to futher summarize this
section, decreasing roughly 150 more words from this section.
|
|
Until now the list of existing tools was written in one line which made it
hard to read and follow, especially since we added links. It is now
expanded into a one-line per item which makes to no difference in the final
PDF.
|
|
Reduction by 15 words.
|
|
Reduction by 7 words.
For a regular GNU/Linux of other unix-like system user, the bit
about ISO C compilers even existing for Microsoft systems more or
less says "despite there being no point ever trying to do science
on a Microsoft system, you *could* hypothetically compile and run
any ISO C program on it". Interesting, but not directly of
interest to this user, who is unlikely to actually want to do it.
A Microsoft user who thinks that s/he can do science on a
Microsoft system will typically think "Microsoft is good, so of
course I can run anything I want on it". So the message here
could more likely be seen as provocative rather than useful,
since this user is unaware of the fundamental problems of
Microsoft as an authoritarian, manipulative, centralised
organisation providing bad software.
So either way, the parenthesis about Microsoft can be safely
removed given the space constraints.
|
|
Reduction by 5 words.
The term "exploratory research" is intended in the specific sense
listed at en.Wikipedia:
https://en.wikipedia.org/wiki/Exploratory_research
to distinguish it from hypothesis testing. The final phases of clinical
(medical) research, for example, to test whether a candidate SARS-CoV-2
vaccine is (i) effective and (ii) safe in homo sapiens, cannot accept the
exploratory methods that are acceptable in astronomy, or in other
exploratory research (which is acceptable in the early stages of medical
research).
Clinical trial registration is aimed at *preventing* scientists from
modifying their methods in a given project:
https://en.wikipedia.org/wiki/Clinical_trial_registration
|
|
One superfluous word was removed.
|
|
Minor wording changes - reduction by 10 words.
|
|
Minor wording improvements; reduction by 10 words.
|
|
For consistency, the principles should either all be nouns, or
all be adjectives. Most are nouns, so this commit switches the
adjectives to nouns.
|
|
Compression by about 40 words. Updating python2 to python3
is often nothing more than modifying print statements, so
removing this doesn't weaken the text by much.
Re-creation helps avoid thinking of watching movies, going to
the beach, reading a novel, when seeing the word "recreation":
https://en.wiktionary.org/wiki/recreation#Usage_notes
The matplotlib sentence was not so clear: now it's a bit shorter
and hopefully clearer.
|
|
Word-length reduction (8 words) of the first part of 3 Principles.
Change in meaning: we can argue that *results* are not part of
science, but science needs aims as well as methods; hypotheses
are needed too, but these overlap between the aims and
methods. So I put "primarily".
|
|
In this commit, the URLs for the 19 "earlier solutions" at the
beginning of "3 Principles" are recovered from
tex/src/paper-long.tex and put behind the package names
as clickable words.
To reduce the chance that these are interpreted as references,
"Project1 (yyy1), Project2 (yyy1)" is changed to "yyy1: Project1,
Project2". We cannot add full references because of the 8000-word
space constraint.
With a minor word improvement, this commit overall reduces the word
count very slightly, by 9, according to
pdftotext paper.pdf |wc paper.txt
before and after the commit.
|
|
Scalability is not just on the size of the project, but also its
complexity, so I added an `and/or complex' to the description of the
scalability principle.
|
|
Someone reading the principles section until now would think that IPOL is
an almosts perfect solution, and for its usecase it certainly is. However,
this is only because of the nature of its work: it only focuses on
algorithms, not usage/analysis which cannot be done in raw ISO C.
So with this commit, I added a new principle on Scalability and discussed
this limitation of IPOL there. To avoid simply lengthening the text, to add
this new principle, I had to remove/summarize some parts that seemed
redundant. In the process, I also removed some of the existing tools (at
the start of the principles section) that had several others in the same
time frame, I have already mentioned (through the "and many more") that
this list is not complete.
Also, the list of people to thank in the acknowledgments is now put in a
one-line per name to be more easily maintainable: Boud and Mohammad-reza
were added, and given that I have sent the paper to several other people
for feedback, I expect the list to get longer.
|
|
A few more minor language edits. For parseable vs parseable, see
https://en.wiktionary.org/wiki/parsable which recommends `parsable`
for formal usage.
|
|
These are mostly minor language edits. There is one significant fix: the
word `typically' in `a non-free software project typically' cannot be
distributed by the project. There is a whole range of licences between
strictly free software definition, strictly OSI open-source definition, and
fully closed source. For example, software with a no-commercial usage
licence (similar to CC-BY-NC) can be publicly redistributed on any server,
as long as there is no requirement of payment or no requirement of payment
that is "commercial" (according to lawyers' interpretation of when a
payment is commercial).
|
|
These are important aspects that are highly relevant to Maneage: its
philosophy (the former) and usability (the latter). To add them, I tried to
summarize some other parts of the paper.
|
|
There weren't any conflicts in this merge.
|
|
Three such cases and they are fixed.
|
|
A few minor issues were found and fixed in the text. I also tried to
shorten it a little further.
|
|
Of the GCC dynamically linked libraries we need to manually add RPATH to
all and for `libstdc++' we also need to tell it to link with
`libiconv'. Until now, the conditional to check for libstdc++ was not
working and thus libiconv wasn't been added to it.
With this commit the conditional has been corrected and is now
working. Also, to help in reading the logs, an echo statement was added
after every call to PatchELF.
|
|
Until now, when a the raw tarball of some software wasn't usable, I would
put it under my own webpage, or `akhlaghi.org/reproduce-software'. That
same address was also used as a backup server. However, now the project has
a proper name: Maneage. So I changed the directory on my own server to
`akhlaghi.org/maneage-software'.
With this commit, this new address has replaced the old one. But to avoid
crashes in projects that haven't yet merged with the main Maneage branch,
the old `reproduce-software' still works (its actually a symbolic link to
the new directory now).
|
|
In the previous commit, we remove the `-static' flag from building PatchELF
because it wasn't necessary any more. Howver, the comment for the check
still included it and could be confusing. This is corrected with this
commit. Also, we don't need the `good_static_libc' variable (that was only
defined to pass onto PatchELF). This has also been corrected.
|
|
Until a few commits ago, PatchELF was built statically because it was used
to patch `libstdc++' at the end of the GCC building phase, but PatchELF
also depends on `libstdc++', so it would crash. However, recently when
patching the GCC libraries, we don't directly apply Patchelf to the
library, first we copy it to a temporary place, do the patching, then put
it in its proper place. So the problem above won't happen any more.
With this commit, I am thus removing the static flag from patchelf and
letting it built dynamically all the time. The main problem was that some
systems don't have a static C++ library, so PatchELF couldn't be built
statically. Instead of adding more checks, we just fixed the core
foundation of the problem.
|
|
A few minor conflicts came up that were easily fixed.
|
|
I forgot to put these in the last commit! They are now implemented.
|
|
I had another look at the text and tried to summarize it a little more
while also fixing several typos that I had just discovered! In the process,
I noticed that we hadn't actually put a link to Maneage's main Git
repository! So we now have the URL as a `git clone' command.
Also, I thought that its better to show the `TARGETS.conf' file (which we
actually talk about) in the file architecture instead of `LOCAL.conf.in'
(which we don't talk about any more!).
Finally, to be more similar with DSJ, the bibliography is now in normal
font size, not footnotesize.
|
|
Until now the software configuration parameters were defined under the
`reproduce/software/config/installation/' directory. This was because the
configuration parameters of analysis software (for example Gnuastro's
configurations) were placed under there too. But this was terribly
confusing, because the run-time options of programs falls under the
"analysis" phase of the project.
With this commit, the Gnuastro configuration files have been moved under
the new `reproduce/analysis/config/gnuastro' directory and the software
configuration files are directly under `reproduce/software/config'. A clean
build was done with this change and it didn't crash, but it may cause
crashes in derived projects, so after merging with Maneage, please
re-configure your project to see if anything has been missed. Please let us
know if there is a problem.
|
|
In the introduction I had mistakenly put "metadata" instead of "workflow",
its corrected with this commit.
|
|
Ryan O'Connor is from RDA and my principle contact for the grant. He also
kindly went over the first draft of the paper and gave useful and
encouraging comments.
|
|
I had also done this in the main branch, but I noticed this commit later!
|
|
This was only relevant for the submitted version, so I am committing it
until the next submission.
|
|
After the submission and reading through the text another time I found some
typo corrections and fixed them. Also now that David is an author, I
removed him from the people to acknowledge (David brought this up himself,
thanks David ;-)).
|
|
Since David is a co-author of the paper, I have removed him from the
Acknowledgments paragraph.
|
|
Since the journal doesn't accept supplementary files during initial
submission, I have put this link on the PDF for the referee and editors to
access if they want.
Also the `tex/img' file was added to the distribution tarball.
|
|
I was using some special Bash feature before to ignore the distribution
directory itself when copying the files, but that had some problems, so I
just used a simple for loop over a `find' command to ignore it. Also, for
now, we don't need BibLaTeX sources in the project (that is primarily for
arXiv), so to help the referee see a more cleaner contents of this
supplement file.
|
|
Thanks David ;-)! I tried to implement as many as I could. For the time
being, I just removed teh `~' between "Section" and its number, and removed
the italics on software names. Let's see what the journal editors say about
it. Otherwise, most of the suggestions were very good and indeed made the
text much better to read.
|
|
David submitted these comments by email, I (Mohammad) am committing it into
the project.
|
|
To make the text easier to read and further comply with the author
guideline, the text was shrank a little more and the two final sections
were also added on "Competing interest" and "Author contributions".
I also found the CODATA logo on Wikipedia in SVG format (vector graphics),
so I replaced the previous pixelated PNG format with the PDF (converted
from SVG).
|
