fix: number lab 6 headings consistently with previous labs

- i.e. use 1, 2, etc, not A, B

Author: arranstewart

assets/workshops/workshop06-solutions.html

@@ -201,7 +201,7 @@ <h1 class="title"><p>CITS5501 lab 6 (week 7) – grammars and syntax-based
 <h2 id="toc-title">Contents</h2>
 <ul>
 <li><a href="#reading" id="toc-reading">Reading</a></li>
-<li><a href="#a.-command-line-argument-parsing" id="toc-a.-command-line-argument-parsing">A. Command-line argument
+<li><a href="#command-line-argument-parsing" id="toc-command-line-argument-parsing">1. Command-line argument
 parsing</a>
 <ul>
 <li><a href="#documenting-command-line-arguments" id="toc-documenting-command-line-arguments">Documenting command-line
@@ -210,16 +210,17 @@ <h2 id="toc-title">Contents</h2>
 command-line argument syntax</a></li>
 <li><a href="#generators" id="toc-generators">Generators</a></li>
 </ul></li>
-<li><a href="#b.-hand-written-parsers" id="toc-b.-hand-written-parsers">B. Hand-written parsers</a></li>
-<li><a href="#c.-testing-grammars-coverage" id="toc-c.-testing-grammars-coverage">C. Testing grammars –
+<li><a href="#hand-written-parsers" id="toc-hand-written-parsers">2.
+Hand-written parsers</a></li>
+<li><a href="#testing-grammars-coverage" id="toc-testing-grammars-coverage">3. Testing grammars –
 coverage</a></li>
 </ul>
 </nav>
 <p></p>
 <h2 id="reading">Reading</h2>
 <p>It is strongly suggested you complete the recommended readings for
-weeks 1-6 <em>before</em> attempting this lab/workshop.</p>
-<h2 id="a.-command-line-argument-parsing">A. Command-line argument
+weeks 1-7 <em>before</em> attempting this lab/workshop.</p>
+<h2 id="command-line-argument-parsing">1. Command-line argument
 parsing</h2>
 <p>A very common place to use grammars is when parsing <em>command-line
 arguments</em> to applications. As an example, we’ll look at a
@@ -343,7 +344,7 @@ <h3 id="generators">Generators</h3>
 <pre><code>&lt;image&gt;      ::= &quot;debian&quot; | &quot;ubuntu&quot; | &quot;ubuntu&quot; | &quot;ubuntu&quot;
                 | &quot;ubuntu&quot; | &quot;fedora&quot;</code></pre>
 </div>
-<h2 id="b.-hand-written-parsers">B. Hand-written parsers</h2>
+<h2 id="hand-written-parsers">2. Hand-written parsers</h2>
 <p>Suppose we wanted to write code ourselves to parse the command-line
 arguments of a program according to a grammar like this.</p>
 <p>For small programs, the simplest way is usally is to implement a
@@ -375,8 +376,7 @@ <h2 id="b.-hand-written-parsers">B. Hand-written parsers</h2>
 either Apache Commons CLI or Picocli, and amend our
 <code>MyDockerLiteProgram</code> class to use one of these libraries to
 parse its command-line arguments.</p>
-<h2 id="c.-testing-grammars-coverage">C. Testing grammars –
-coverage</h2>
+<h2 id="testing-grammars-coverage">3. Testing grammars – coverage</h2>
 <p>Recall that when testing something that can be represented as a
 grammar, there are different levels of <em>coverage</em> we might aim to
 achieve.</p>

assets/workshops/workshop06-solutions.md

@@ -21,10 +21,10 @@ include-before: |
 
 ## Reading
 
-It is strongly suggested you complete the recommended readings for weeks 1-6
+It is strongly suggested you complete the recommended readings for weeks 1-7
 *before* attempting this lab/workshop.
 
-## A. Command-line argument parsing
+## 1. Command-line argument parsing
 
 A very common place to use grammars is when parsing *command-line arguments*
 to applications. As an example, we'll look at a simplified version of the
@@ -205,7 +205,7 @@ to get
 \endsolbox
 
 
-## B. Hand-written parsers
+## 2. Hand-written parsers
 
 Suppose we wanted to write code ourselves to parse the command-line arguments of a program
 according to a grammar like this.
@@ -249,7 +249,7 @@ its command-line arguments.
 \endgenericbox
 
 
-## C. Testing grammars -- coverage
+## 3. Testing grammars -- coverage
 
 Recall that when testing something that can be represented
 as a grammar, there are different levels of *coverage*

assets/workshops/workshop06.html

@@ -201,7 +201,7 @@ <h1 class="title"><p>CITS5501 lab 6 (week 7) – grammars and syntax-based
 <h2 id="toc-title">Contents</h2>
 <ul>
 <li><a href="#reading" id="toc-reading">Reading</a></li>
-<li><a href="#a.-command-line-argument-parsing" id="toc-a.-command-line-argument-parsing">A. Command-line argument
+<li><a href="#command-line-argument-parsing" id="toc-command-line-argument-parsing">1. Command-line argument
 parsing</a>
 <ul>
 <li><a href="#documenting-command-line-arguments" id="toc-documenting-command-line-arguments">Documenting command-line
@@ -210,16 +210,17 @@ <h2 id="toc-title">Contents</h2>
 command-line argument syntax</a></li>
 <li><a href="#generators" id="toc-generators">Generators</a></li>
 </ul></li>
-<li><a href="#b.-hand-written-parsers" id="toc-b.-hand-written-parsers">B. Hand-written parsers</a></li>
-<li><a href="#c.-testing-grammars-coverage" id="toc-c.-testing-grammars-coverage">C. Testing grammars –
+<li><a href="#hand-written-parsers" id="toc-hand-written-parsers">2.
+Hand-written parsers</a></li>
+<li><a href="#testing-grammars-coverage" id="toc-testing-grammars-coverage">3. Testing grammars –
 coverage</a></li>
 </ul>
 </nav>
 <p></p>
 <h2 id="reading">Reading</h2>
 <p>It is strongly suggested you complete the recommended readings for
-weeks 1-6 <em>before</em> attempting this lab/workshop.</p>
-<h2 id="a.-command-line-argument-parsing">A. Command-line argument
+weeks 1-7 <em>before</em> attempting this lab/workshop.</p>
+<h2 id="command-line-argument-parsing">1. Command-line argument
 parsing</h2>
 <p>A very common place to use grammars is when parsing <em>command-line
 arguments</em> to applications. As an example, we’ll look at a
@@ -326,7 +327,7 @@ <h3 id="generators">Generators</h3>
 chooses one randomly. How would you alter the grammar so that the image
 “<code>ubuntu</code>” is chosen twice as often as the others?</li>
 </ul>
-<h2 id="b.-hand-written-parsers">B. Hand-written parsers</h2>
+<h2 id="hand-written-parsers">2. Hand-written parsers</h2>
 <p>Suppose we wanted to write code ourselves to parse the command-line
 arguments of a program according to a grammar like this.</p>
 <p>For small programs, the simplest way is usally is to implement a
@@ -358,8 +359,7 @@ <h2 id="b.-hand-written-parsers">B. Hand-written parsers</h2>
 either Apache Commons CLI or Picocli, and amend our
 <code>MyDockerLiteProgram</code> class to use one of these libraries to
 parse its command-line arguments.</p>
-<h2 id="c.-testing-grammars-coverage">C. Testing grammars –
-coverage</h2>
+<h2 id="testing-grammars-coverage">3. Testing grammars – coverage</h2>
 <p>Recall that when testing something that can be represented as a
 grammar, there are different levels of <em>coverage</em> we might aim to
 achieve.</p>

assets/workshops/workshop06.md

@@ -21,10 +21,10 @@ include-before: |
 
 ## Reading
 
-It is strongly suggested you complete the recommended readings for weeks 1-6
+It is strongly suggested you complete the recommended readings for weeks 1-7
 *before* attempting this lab/workshop.
 
-## A. Command-line argument parsing
+## 1. Command-line argument parsing
 
 A very common place to use grammars is when parsing *command-line arguments*
 to applications. As an example, we'll look at a simplified version of the
@@ -162,7 +162,7 @@ Now put the original grammar back in and compile it again.
 
 
 
-## B. Hand-written parsers
+## 2. Hand-written parsers
 
 Suppose we wanted to write code ourselves to parse the command-line arguments of a program
 according to a grammar like this.
@@ -206,7 +206,7 @@ its command-line arguments.
 \endgenericbox
 
 
-## C. Testing grammars -- coverage
+## 3. Testing grammars -- coverage
 
 Recall that when testing something that can be represented
 as a grammar, there are different levels of *coverage*