March 10, 2021:
Created repo. The GitHub commit was going to be helpful in reconstructing the creating process. To recapitulate, I was designing a markup, which output HTML with Mathjax-readable LaTeX in it. It should distinguish normal, italic, and bold text, and it should have a math mode too. The project was named “Porphyrin”, which was derived from the Greek root for ‘purple’.
It occurred to me, inspired by Markdown, there was an easy parsing strategy as below. Let us say a mark consisted of an ASCII character repeated several times. It marked the beginning and the end of an element. In so doing, there couldn’t be any ambiguity, as long as the mark didn’t appear in the element’s content.
April 19:
A run of text might consist of the hierarchy of section, paragraph, sentence, and text. Each of them was represented by an object which output HTML element. When the parent object was being parsed, it parsed its child objects. In this manner, parsing was done recursively.
The parent object passed, to its child object, the child’s source and additional information on the position relative to the parent’s content. Such information, to be used in error messages, included the line number, the column number, the left fragment of the beginning line, and the right fragment of the ending line. Every object had to store these fields.
Similarly, there should be corresponding classes of stanza, table, and image, regarded as the same level of section. Here, a stanza was used to display verses and proof. Section, stanza, and table were set to have symmetrical structure in the hierarchy. They all inherited a parent class to enhance code reuse.
May 4:
There was one method which parsed the block level objects (like a section) from the global source. Another method parsed the group of inline level objects (like a paragraph), when a separating token was met. Yet another method parsed the group of inline level objects (like a sentence).
The text was to be preprocessed before it was put into a HTML span. Most importantly, &, <, >, ", and ' had to be escaped in HTML. Additionally, strings could be trimmed of leading and trailing whitespaces. I could even have several forbidden characters automatically removed, but used in the source as syntactic sugar to guide myself.
For instance, suppose that === denotes the beginning and end of a section, and that @@ denotes beginning and end of a text fragment, and that ' denotes a newline.
Then below is a valid piece of Porphyrin source:
===
@@Hello world!@@ '
@@Who am I?@@
===
This becomes the HTML:
<div>
<p><span>Hello world!</span></p>
<p><span>Who am I?</span></p>
</div>
May 5:
Two directories were input into the main function, one of them containing the source, another containing the HTML. Using Python module os to compare time stamps, I was able to single out the input files newer than output files, mimicking the effect of a makefile. This way, when I updated a source of a post, only the updated post was converted again.
Wrote some unity tests. They started from a single “hello world” to tables, code listings, and mathematics. When the program stabilized, newly generated HTML texts would be compared to reference answers.
May 7:
The link was a special construction. An address, being enclosed by \\, followed a fragment of text, and they were combined as an anchor when being parsed.
For instance, consider the Porphyrin source:
@@English Wikipedia@@ \\https://en.wikipedia.org\\
This becomes the HTML:
<a href="https://en.
May 11:
That said, it took more time and caution than I thought to get the parser right. For example, within a loop, a section called its method to snip a fragment of source for a paragraph. Should the method immediately call the paragraph constructor? If so, how did the loop know the next position in the section source to look? Or should the function return the snipped fragment and the mark only, so the new position could be calculated? If so, in the loop the section was obliged to construct the paragraph according to the enclosing marks, and there would be more repetitive code. In the end, I returned both the paragraph and next position, getting the advantage of both solutions.
May 19:
Embarked the task of parsing math. Both letters and signs, let us say, were encoded by precisely two characters. The token for letters began with one of .#&@$, and ended in one of the alphabets AaBb ... Zz, and the token for signs began with one of ./+-*=~\|^<>%, and ended in one of the numbers 01 ... 9.
I allowed three kinds of composite objects, namely the term of fraction, the term with superscript and subscript, and the term of vector and matrix. They were denoted respectively by the plain brackets (.a, .b), [.a: .b: .c], and {.a; .b; .c; .d}. Meanwhile, .(.), .[.], .{.}, .<.>, and .\.|, are literal brackets.
For instance, consider the source:
(.-.b +0 $R.([.2:.b:] .- .4.a.c.), .2.a)
This becomes the LaTeX code in a span:
<span>\(\dfrac {- b \pm \surd \left( {b} ^ {2} _ {} - 4 a c \right)} {2 a}\)</span>
May 26:
Interpretation of “Porphyrin” succeeded for the first time!
May 27:
Except in enclosing marks, I made the document ignore whitespace characters anywhere else. However, this made it more difficult to find the next position when snipping the very next fragment of source. After much consideration, I found that there just had to be a function which found the very next non-whitespace character.
June 3:
Created repository for the website.
It was named “Photoluminescence”, with the allusion to light, since this word was respectively derived from Greek and Latin roots for ‘light’.
The Photoluminescence repository was to be copied by a bash script into the GitHub Page repository, whenever I updated the former. This way, I could make little changes as I wanted to, without polluting the GitHub Page repository. The directories was so organized, that posts were collected into a dedicated directory, and pages into another. Here, posts were standalone articles. Pages, including index.html, displayed linked post titles organized under the same category.
A category was either a date, genre, series, or a tag.
June 5:
Sketched a Python script playing the role similar to a makefile. First, it searched the Porphyrin markup in a directory, and converted them into HTML. Second, it combined the head, the header, and the footer with the main text of every post. Third, it wrote category pages, which itself listed other categories. A JSON file, which Python could read with module json , was to be curated. When a category page was being written, data from the JSON file helped the program to map the category name to the path to that page. Special consideration was necessary for strings of dates, since they were supposed to be grouped by month. For instance, the category “June 2021” was a tag, and the page /page/june-2021.html was to be updated constantly. To simplify matters, I mandated that every post should have a unique date, saved as six digits (two for each of year, month, and day), from which a function returned the month and the corresponding path.
❧ mostly June 27, 2021