chore: Fix all errors

5 files changed, 12 insertions, 14 deletions

diff --git a/dunbar b/dunbar
-Subproject 8b2fb33649d4941d779eb357a96a18d9206a16e
+Subproject e7cbbfc06470f038f325216a1503d27f36d8dc6
diff --git a/ext/global.du b/ext/global.du
index 1e31ec6..888fefc 100644
--- a/ext/global.du
+++ b/ext/global.du
@@ -96,6 +96,7 @@ The gap is only for visual purposes.
 
 # Other
 
+'define line <hr>
 'define due_for_rework [url /rework.html =[*[Due for rework]*]=]
 
 'define_block contents <div id="contents-container"><h2 id="contents">Contents</h2> <a class="h-anchor" href="#contents" aria-hidden="true">#</a> </div>
diff --git a/generate.sh b/generate.sh
index 2194fb5..10ead82 100755
--- a/generate.sh
+++ b/generate.sh
@@ -34,7 +34,6 @@ EOF
 	/usr/bin/env dash ./dunbar/dunbar_awk/dunbar.sh html  \
 		-i                                                \
 		-e ./ext/pagenav.awk -e ./ext/presentation.awk    \
-		-wo                                               \
 		./ext/global.du \
 		$(find "$GEN_DIR" -type f -name "*.du")
 # }}}
diff --git a/src/blog/sane-explanation-of-compilers/part-1.du b/src/blog/sane-explanation-of-compilers/part-1.du
index d9b58ba..33d8a1a 100644
--- a/src/blog/sane-explanation-of-compilers/part-1.du
+++ b/src/blog/sane-explanation-of-compilers/part-1.du
@@ -658,7 +658,7 @@ If you want to learn more, I would highly suggest:
 We already decided that the lexer will output tokens (and characters) to the parser, but we didn't talk about what the parser is supposed to output.
 It definitely has to be some sort of structural representation of the overall code, for example, for `[3 + 1 * 2]` we have to be able to easily find out what the left and right handsides of the `[+]` and `[*]` are.
 
-'footnoe nomnoml The graphics are made with [url https://nomnoml.com/ nomnoml] by [url https://github.com/skanaar Daniel Kallin]
+'footnote nomnoml The graphics are made with [url https://nomnoml.com/ nomnoml] by [url https://github.com/skanaar Daniel Kallin]
 
 Let's draw out[$nomnoml] this relationship, where the left arrow connects to the left handside and the right accordingly:
 
@@ -1065,20 +1065,20 @@ The way we created that lexer and parser worked, but it wasn't very useful and h
    RULE1 { yylval.num = 129; return TOKEN; }
    RULE2 { yylval.chr = 'a'; return TOKEN; }
 
-   Inside C blocks for grammar rules we can reference the token values with `[$i]`, where `[i]` is the i'th "token" in the expression.
-   For example, in this rule, `[$1]` would be `[(]`, `[$3]` would be value of token `[B]` and `[$5]` would be the value of the rule name:
+   Inside C blocks for grammar rules we can reference the token values with `[\$i]`, where `[i]` is the i'th "token" in the expression.
+   For example, in this rule, `[\$1]` would be `[(]`, `[\$3]` would be value of token `[B]` and `[\$5]` would be the value of the rule name:
 
    ```yacc
    rule : ( A B ) rule
          ;
 
-   You can set rule "return" values by setting the variable `[$$]`:
+   You can set rule "return" values by setting the variable `[\$$]`:
 
    ```yacc
    rule : LBRACE rule RBRACE { $$ = 10; }
 
    The way you set it's type is discussed later.
-   However, `[$i]` isn't of type union, we cannot do something like `[$i.num]`, it is the precise value that was set for the token.
+   However, `[\$i]` isn't of type union, we cannot do something like `[\$i.num]`, it is the precise value that was set for the token.
    Therefore, we also need to define which value from the union every token will set, which is done by adding `[<PROPERTY>]` before every defined token (and `[PROPERTY]` is a property name inside the union):
 
    ```yacc
@@ -1190,8 +1190,8 @@ The way we created that lexer and parser worked, but it wasn't very useful and h
    For the expression of `[expr]` we'll "return" a node with the value of the math operator and left and right will be the returned values.
    Inside start, after we've parsed an `[expr]`, we'll print out the "returned" tree and free it's memory.
 
-   I'm putting returned in quotes, because (as mentioned), we'll just be setting the value of `[$$]`.
-   `[$$]`'s type is set with the `[%type]` option, which works exactly like `[%token]`, but with grammar rule names.
+   I'm putting returned in quotes, because (as mentioned), we'll just be setting the value of `[\$$]`.
+   `[\$$]`'s type is set with the `[%type]` option, which works exactly like `[%token]`, but with grammar rule names.
    However, this means that `[node]` must be available in `[%union]`, which is unfortunate but isn't a problem, we'll just add it.
 
    Now, finally, it's time to include our `[tree.h]` in `[parser.y]`, but we'll also need to include it in `[lexer.l]`.
diff --git a/src/teaching/oop-2023/week1/good-software.du b/src/teaching/oop-2023/week1/good-software.du
index ce36c28..94bf593 100644
--- a/src/teaching/oop-2023/week1/good-software.du
+++ b/src/teaching/oop-2023/week1/good-software.du
@@ -404,14 +404,11 @@ for (int i = 0; i < rows; i++) {
 При добрия вариант, получаваме нова информация, че това запълване се случва понеже ще подаваме към някаква си `[functionX]`, и че евентуално може да има други функции, при които празни клетки може да не се обозначават с `['\0']`.
 В лошия можем да стигнем до същото заключение като погледнем самия код.
 
-<!--
-\n
+:comment
 
 Всичко това е много хубаво, обаче цитирайки Дийкстра, малки изолирани примери не са достатъчни:
 
-
-
-:middle
+:middle_slide
 
 .quote For practical reasons, the demonstration programs must be small, many times smaller than the "life-size programs" I have in mind. My basic problem is that precisely this difference in scale is one of the major sources of our difficulties in programming!
 
@@ -424,7 +421,8 @@ for (int i = 0; i < rows; i++) {
 
 Окуражавам ви да разгледате решенията, да ги сравните с вашите и поне да придобиете някаква интуиция за нещата.
 Така да мислиш не е лесно, отнема време и усилия.
--->
+
+
 
 Умението да разрешиш един проблем *[не те]* прави добър програмист, да го разрешиш по четим, разширяем, лесен, ефикасен, ... начин *[те]* прави добър програмист.