aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMohammad Akhlaghi <mohammad@akhlaghi.org>2021-04-09 14:09:30 +0100
committerMohammad Akhlaghi <mohammad@akhlaghi.org>2021-04-09 14:09:30 +0100
commit4ccf01420f36c705302fdcde9a94c72676256665 (patch)
treeb5f29d505fb7a7176d251a09d5901b54512f6851
parent832aca819ee88c4bb61504e7f9215dc7c50a625e (diff)
Minor corrections on previous copyedit
Being immutable doesn't necessary mean that something is always present, so an "always present" was also added for the reason we recommend a Git hash. The end of the sentence was also slightly summarized to allow the extra few words. The re-wording of the conclusion of Active papers, was great! I just changed the "likely" to "possible", because as Konrad mentioned in Commit a63900bc5a8, he is now using Guix.
-rw-r--r--paper.tex2
-rw-r--r--tex/src/appendix-existing-solutions.tex2
2 files changed, 2 insertions, 2 deletions
diff --git a/paper.tex b/paper.tex
index 06596df..53caf4b 100644
--- a/paper.tex
+++ b/paper.tex
@@ -451,7 +451,7 @@ There is a thoroughly elaborated customization checklist in \inlinecode{README-h
The current project's Git hash is provided to the authors as a \LaTeX{} macro (shown here in the abstract and acknowledgments), as well as the Git hash of the last commit in the Maneage branch (shown here in the acknowledgments).
These macros are created in \inlinecode{initialize.mk}, with other basic information from the running system like the CPU details (shown in the acknowledgments).
-As opposed to Git ``tag''s, the hash is a core concept in the Git paradigm and is immutable for a given history, which is why it is recommended for precisely identifying a project version.
+As opposed to Git ``tag''s, the hash is a core concept in the Git paradigm and is immutable and always present in a given history, which is why it is the recommended version identifier.
Figure \ref{fig:branching} shows how projects can re-import Maneage at a later time (technically: \emph{merge}), thus improving their low-level infrastructure: in (a) authors do the merge during an ongoing project;
in (b) readers do it after publication; e.g., the project remains reproducible but the infrastructure is outdated, or a bug is fixed in Maneage.
diff --git a/tex/src/appendix-existing-solutions.tex b/tex/src/appendix-existing-solutions.tex
index 42a1408..8bbbe1c 100644
--- a/tex/src/appendix-existing-solutions.tex
+++ b/tex/src/appendix-existing-solutions.tex
@@ -287,7 +287,7 @@ In such cases, the data must not be publicly released, but the methods that were
Furthermore, since all reading and writing is currently done in the HDF5 file, it can easily bloat the file to very large sizes due to temporary files.
These files can later be removed as part of the analysis, but this makes the code more complicated and hard to read/maintain.
For example the Active Papers HDF5 file of \citeappendix[in \href{https://doi.org/10.5281/zenodo.2549987}{zenodo.2549987}]{kneller19} is 1.8 giga-bytes.
-This is not a fundamental feature of the approach, but rather an effect of the initial implementation; future improvements are likely.
+This is not a fundamental feature of the approach, but rather an effect of the initial implementation; future improvements are possible.