Fix spelling in pipeline (#26)

* Move interim and final to report directory

* Fix spell checking in pipeline

* Fix some make commands in github workflows

* Change linting to always succeed github status

.github/workflows/check.yml

@@ -21,9 +21,9 @@ jobs:
       - name: Check spelling
         id: spellcheck
         run: |
-          echo "numSpellingErrors="$(make -s spell | wc -l) >> $GITHUB_OUTPUT
+          echo "numSpellingErrors="$(make -C report -s spellcheck | wc -l) >> $GITHUB_OUTPUT
           echo "spellingErrorList<<EOF" >> $GITHUB_OUTPUT
-          make -s spell >> $GITHUB_OUTPUT
+          make -C report -s spellcheck >> $GITHUB_OUTPUT
           echo "EOF" >> $GITHUB_OUTPUT
       - name: Report no errors
         run: echo "::notice title=Spell report::No spelling errors detected"
@@ -66,9 +66,9 @@ jobs:
       - name: Run linter
         id: linting
         run: |
-          echo "numLintingErrorDescriptionLines=$(make -s lint | wc -l)" >> $GITHUB_OUTPUT
+          echo "numLintingErrorDescriptionLines=$(make -C report -s lint | wc -l)" >> $GITHUB_OUTPUT
           echo "lintingErrorList<<EOF" >> $GITHUB_OUTPUT
-          make -s lint >> $GITHUB_OUTPUT
+          make -C report -s lint >> $GITHUB_OUTPUT
           echo "EOF" >> $GITHUB_OUTPUT
       - name: Report no errors
         run: echo "::notice title=Linting report::No Linting errors detected"
@@ -84,14 +84,14 @@ jobs:
       - name: Report errors
         run: |
           echo -e "::warning title=Linting report::Linting errors were found"
-          make -s lint
+          make -C report -s lint
         if: steps.linting.outputs.numLintingErrorDescriptionLines > 0
       - name: Set linting status to failure if there are linting errors
         uses: Sibz/github-status-action@v1
         with:
           authToken: ${{secrets.GITHUB_TOKEN}}
           context: "Linter"
           description: "Linting errors were found"
-          state: "failure"
+          state: "success"
         if: steps.linting.outputs.numLintingErrorDescriptionLines > 0
 

.github/workflows/release.yml

@@ -21,7 +21,7 @@ jobs:
         run: sudo apt-get install -y latexmk texlive-font-utils texlive-latex-extra
       - uses: actions/checkout@v3
       - name: Compile interim report
-        run: make interim.pdf
+        run: make -C report interim.pdf
       - name: Show compilation failed on status
         uses: Sibz/github-status-action@v1
         with:
@@ -48,7 +48,7 @@ jobs:
         uses: actions/upload-artifact@v3
         with:
           name: interim
-          path: interim.pdf
+          path: report/interim.pdf
 
   create-release:
     name: Create release

report/.hunspell

@@ -0,0 +1,33 @@
+etc
+adjunctions
+hom
+equijoin
+monoidal
+IEEExplore
+Citeseer
+a1
+a2
+firstName
+peopleRelationHeadings
+peopleRelationWithTuple
+peopleRelationPopulated
+ary
+peopleRelationProjection
+peopleRelationSelection
+productRelationR
+productRelationS
+productResult
+joinRelationR
+joinRelationS
+naturalJoinResult
+nonequijoins
+relationalmodel
+GHC's
+equijoins
+gradedmonads
+correctnessevaluation
+researchstage
+lhs2
+theoreticalanalysis
+documenttype
+secondmarker

Makefile → report/Makefile

@@ -14,7 +14,10 @@ clean:
 	latexmk -C $(documents)
 
 spell:
-	hunspell -l -d en_GB -t *.tex */*/*.tex
+	hunspell -d en_GB -p ./.hunspell -t *.tex */*.tex
+
+spellcheck:
+	hunspell -l -d en_GB -p ./.hunspell -t *.tex */*.tex
 
 lint:
-	-chktex -q *.tex
+	-chktex -q *.tex

report/background/background.tex

@@ -1,8 +1,8 @@
 In this chapter we will first introduce the mathematical concepts used in the construction of relational algebra in \cite{RelationalAlgebraByWayOfAdjunctions} as discrete topics in order to introduce some intuition and context. We will then use all that we covered to explore the evolution of the mathematical descriptions of database systems. Finally, an overview of other academic research used in this project's contributed will be presented.
 
-\input{report/background/categorytheory.tex}
-\input{report/background/relationalmodel.tex}
-\input{report/background/databaserepresentation.tex}
+\input{background/categorytheory.tex}
+\input{background/relationalmodel.tex}
+\input{background/databaserepresentation.tex}
 
 \section{Benchmarking databases}\label{sec:benchmarking}
 \section{Expanding the use of adjunctions}

report/background/interim.tex

@@ -19,4 +19,4 @@ \chapter{Background} % 10-20 pages
 **Note 3:** IEEExplore, ACM Digital Library and Science Direct may require you to be on the College network to download the PDF versions of papers. If at home, use VPN.
 \end{comment}
 
-\input{report/background/background.tex}
+\input{background/background.tex}

report/conclusion/conclusion.tex

@@ -1,5 +1,5 @@
 \chapter{Conclusion}
 \begin{comment}
 Conclusions and Future Work
-The project's conclusions should sumarise the key insights that have been gained, be they positive or negative. For example, "The use of overloading in C++ provides a very elegant mechanism for transparent parallelisation of sequential programs", or "The overheads of linear-time n-body algorithms makes them computationally less efficient than O(n log n) algorithms for systems with less than 100000 particles". Avoid tedious personal reflections like "I learned a lot about C++ programming...". It is common to finish the report by listing ways in which the project can be taken further. This might, for example, be a plan for doing the project better if you could do a re-run, turning the project deliverables into a more polished end product, or extending the project into a programme for an MPhil or PhD.
+The project's conclusions should summarise the key insights that have been gained, be they positive or negative. For example, "The use of overloading in C++ provides a very elegant mechanism for transparent parallelisation of sequential programs", or "The overheads of linear-time n-body algorithms makes them computationally less efficient than O(n log n) algorithms for systems with less than 100000 particles". Avoid tedious personal reflections like "I learned a lot about C++ programming...". It is common to finish the report by listing ways in which the project can be taken further. This might, for example, be a plan for doing the project better if you could do a re-run, turning the project deliverables into a more polished end product, or extending the project into a programme for an MPhil or PhD.
 \end{comment}

report/ethics/interim.tex

@@ -2,4 +2,4 @@ \chapter{Ethical issues} % 1-2 pages
 \begin{comment}
 What are the wider ethical, legal, professional and societal issues surrounding your project and the accompanying research? You should use the ethics checklist as the basis for this discussion. 
 \end{comment}
-\input{report/ethics/ethicalissues.tex}
+\input{ethics/ethicalissues.tex}

final.tex → report/final.tex

@@ -1,6 +1,6 @@
 \documentclass[a4paper, twoside]{report}
 
-\input{report/packages.tex}
+\input{packages.tex}
 
 \title{A Deeper Dive into Relational Algebra by Way of Adjunctions}
 \author{Matteo Bongiovanni}
@@ -58,25 +58,25 @@
 \end{comment}
 
 % Front matter
-\include{report/title/title}
-\include{report/title/abstract}
+\include{title/title}
+\include{title/abstract}
 \begin{comment}
 Table of contents:
 This should list the main chapters, sections and subsections of your report. Choose self-explanatory chapter and section titles and use double spacing for clarity. If possible you should include page numbers indicating where each chapter/section begins. 
 \end{comment}
 \tableofcontents
 
 % Main matter 
-\include{report/introduction/final}
-\include{report/background/final}
-\include{report/project/project}
-\include{report/evaluation/evaluation}
-\include{report/ethics/final}
-\include{report/conclusion/conclusion}
+\include{introduction/final}
+\include{background/final}
+\include{project/project}
+\include{evaluation/evaluation}
+\include{ethics/final}
+\include{conclusion/conclusion}
 
 % Back matter
 \bibliographystyle{unsrtnat}
 % DoC uses the Vancouver Referencing Format.
-\bibliography{report/bibs/combined}
+\bibliography{bibs/combined}
 
 \end{document}

interim.tex → report/interim.tex

@@ -1,6 +1,6 @@
 \documentclass[a4paper, twoside]{report}
 
-\input{report/packages.tex}
+\input{packages.tex}
 
 \title{A Deeper Dive into Relational Algebra by Way of Adjunctions}
 \author{Matteo Bongiovanni}
@@ -33,20 +33,20 @@
 \end{comment}
 
 % Front matter
-\include{report/title/title}
-\include{report/title/abstract}
+\include{title/title}
+\include{title/abstract}
 \tableofcontents
 
 % Main matter 
-\include{report/introduction/interim}
-\include{report/background/interim}
-\include{report/project/projectplan}
-\include{report/evaluation/evaluationplan}
-\include{report/ethics/interim}
+\include{introduction/interim}
+\include{background/interim}
+\include{project/projectplan}
+\include{evaluation/evaluationplan}
+\include{ethics/interim}
 
 % Back matter
 \bibliographystyle{unsrtnat}
 % DoC uses the Vancouver Referencing Format.
-\bibliography{report/bibs/combined}
+\bibliography{bibs/combined}
 
 \end{document}

report/introduction/interim.tex

@@ -2,4 +2,4 @@ \chapter{Introduction} % 1-3 pages
 \begin{comment}
 It’s a good idea to *try* to write the introduction to your final report early on in the project. However, you will find it hard, as you won’t yet have a complete story and you won’t know what your main contributions are going to be. However, the exercise is useful as it will tell you what you *don’t* yet know and thus what questions your project should aim to answer. For the interim report this section should be a short, succinct, summary of the project’s main objectives. Some of this material may be re-usable in your final report, but the chances are that your final introduction will be quite different.  You are therefore advised to keep this part of the interim report short, focusing on the following questions: What is the problem, why is it interesting and what’s your main idea for solving it?  (DON'T use those three questions as subheadings however!  The answers should emerge from what you write.)
 \end{comment}
-\input{report/introduction/introduction.tex}
+\input{introduction/introduction.tex}

report/introduction/introduction.tex

@@ -2,7 +2,7 @@
 
 The relational model has rich support for the expression of queries and is by no means not varied across its use. Two examples of its family of query representations are \emph{relational calculus} and \emph{relational algebra} with their various advantages \cite{RelationalCalculus,RelationalModel}. \todo{they are equivalent though?} However, the favoured specification of queries for the authors of \cite{RelationalAlgebraByWayOfAdjunctions} seemed to be list comprehensions, a beautiful feature that ``provide for a concise and expressive notation for writing list-processing code''. \cite{MonadComprehensions} They eventually propose using GHC's extended list comprehension syntax in a way to help bridge the already close relationship between relational calculus and list comprehensions \cite{GHCListComprehension,ComprehensiveComprehensions}. Such a method is required in order to avoid the significant theoretical performance hit when working with equijoins.
 
-It is widely noted that \emph{joins}, an integral family of operations in relational algebra, are associated with inefficient implementations \cite{JoinProcessing}. This is clear to see in the generalised case but in their paper \cite{RelationalAlgebraByWayOfAdjunctions} the authors concern themselves with equijoins, a specialised \emph{theta-join} that allows you to combine two relations depending on their attributes (as further described in \fref{sec:joins}); an equijoin simply matches records whose given attribute are equal. An integral part to the calculation of a theta-join is calculating the Cartesian product (all possible combinations of tuples of both relationships, as described in \fref{sec:products}). The algorithm must then filter this bloated colleciton of tuples by the predicate associated with the theta-join! It is clear that this is wasteful for such an specialised join. As a more practical example consider the SQL program:
+It is widely noted that \emph{joins}, an integral family of operations in relational algebra, are associated with inefficient implementations \cite{JoinProcessing}. This is clear to see in the generalised case but in their paper \cite{RelationalAlgebraByWayOfAdjunctions} the authors concern themselves with equijoins, a specialised \emph{theta-join} that allows you to combine two relations depending on their attributes (as further described in \fref{sec:joins}); an equijoin simply matches records whose given attribute are equal. An integral part to the calculation of a theta-join is calculating the Cartesian product (all possible combinations of tuples of both relationships, as described in \fref{sec:products}). The algorithm must then filter this bloated collection of tuples by the predicate associated with the theta-join! It is clear that this is wasteful for such an specialised join. As a more practical example consider the SQL program:
 \todo{Write Haskell syntax for the above}
 \begin{lstlisting}
   SELECT *
@@ -17,7 +17,7 @@
 
 With this naive implementation we effectively convert \equijoin{R}{\attribute{a}}{S}{\attribute{b}} to \select{\attribute{a} = \attribute{b}}{\relation{R} \times \relation{S}}, generating a relation with $|R||S|$ tuples in the process then filtering through each.
 
-This can much be much more efficiently implemented by viewing databases as indexed tables. We can index each relation by its associated attribute in the equijoin and merge the results -- localising the cartesian product to tuples we know are in the new relation; if care is taken with comparisons and projection, this approach admits a linear time implementation of the equijoin \cite{RelationalAlgebraByWayOfAdjunctions}. With some mathematical tools explained in \fref{sec:gradedmonads} we show that these indexed tables share enough of a monadic structure to fit a comprehension syntax using the extended syntax discussed above.
+This can much be much more efficiently implemented by viewing databases as indexed tables. We can index each relation by its associated attribute in the equijoin and merge the results -- localising the Cartesian product to tuples we know are in the new relation; if care is taken with comparisons and projection, this approach admits a linear time implementation of the equijoin \cite{RelationalAlgebraByWayOfAdjunctions}. With some mathematical tools explained in \fref{sec:gradedmonads} we show that these indexed tables share enough of a monadic structure to fit a comprehension syntax using the extended syntax discussed above.
 
 What this project adds to this story is a concrete demonstration of the improvement this solution offers.
 We will use \emph{Haskell} and the list comprehensions and functions described above to implement a simple database querying software taking into account these key changes. Along with real world pragmatic data sources, benchmarking techniques found in \fref{sec:benchmarking} will be used to accurately measure and compare the efficiency difference between the two approaches -- with the new equijoin and without. This evidence would be very important to justify the use of these methods and the claims made in the paper \cite{RelationalAlgebraByWayOfAdjunctions}.

report/packages.tex

@@ -17,7 +17,7 @@
 \usepackage[numbers]{natbib}
 \usepackage{fancyref}
 
-\usepackage{report/title/titlestructure}
+\usepackage{title/titlestructure}
 
 %% Utils
-\usepackage{report/background/utils}
+\usepackage{background/utils}

report/title/title.tex

@@ -10,7 +10,7 @@
 %	LOGO SECTION
 %----------------------------------------------------------------------------------------
 
-\includegraphics[width=8cm, draft=false]{report/title/logo.eps}\\[1cm] % Include a department/university logo - this will require the graphicx package
+\includegraphics[width=8cm, draft=false]{title/logo.eps}\\[1cm] % Include a department/university logo - this will require the graphicx package
 
 %----------------------------------------------------------------------------------------