maddy VS SauSaGe

Since I offloaded my markdown parsing to maddy, I did not test for it because it was not my own code. As a result, it was difficult to find parts that I could test. I mostly created my test cases for end to end testing. Since the number of things to test for is always numerous, I ended up finding a few things I could test for. But, I definitely am not satisfied with the number of tests I currently have and will be adding more in the future.

Across all the JavaScript-based SSGs, palpatine is developed from the ground up using C++ and CMake as the build system. As the developer and maintainer of palpatine my main concern is to make it lightning fast compared to others. Currently, palpatine1.5 can generate a static site in less than 1 second. I've also made sure that it is easy to use, with a simple command line interface. The documentation is also precise and easy to follow. However, it is lacking one of the core features, supporting markdown files fully. I've been working on this feature for the past few days and I found a header-only Markdown parser library maddy. But it seems that it has been more than a year since the last commit was made to the library. I'm not sure if it is still being maintained. CMake was quite upset about how outdated it was.

Taking inspiration from Docusaurus, I added full markdown parsing support to my SSG. I chose to add this because it was a core component of my SSG that remained incomplete. Instead of adding a nice-to-have feature, I figured it would be best to complete the core functionality of my SSG first. Instead of coding my own markdown parsing, it was much easier to simply use a markdown parsing library which already existed. I did this by using a maddy, a C++ markdown parsing library. The process of using the library was very straightforward, although calling its methods did noticeably slow down the html generation. After verifying that it worked with my SSG, I removed my initial implementation of markdown parsing.

The following is my PR to his repo to test his CI: pull18

This week, I set up CI for my SSG project. This involves creating a GitHub workflow for GitHub Actions to use. I started with one of the starter workflows. Specifically I used the msbuild one. To give a brief explanation of what adding this file will do, upon pushing changes or, a pull request it will create an environment that can be used to run my program. This is helpful if any tests, or other checks need to be made to verify that everything is in working order after changes to the project have been made.

This week, I added a testing module to my SSG. Since my SSG was created using C++, I used Catch2 as my testing framework. I chose Catch2 as my testing framework since it seemed to be the most popular among C++ developers, and it was all contained within a single header file.

The experience in rebasing my code went very smoothly. I was surprised how easy it was to squash all my multiple commits into a single commit. The process was straightforward with a bit of guidance from the on-screen instructions as well as the instructions of the lab. This was the commit I made.

In this lab, I added to my SSG program (SauSaGe) in order to demonstrate the process of working with and merging parallel branches in a project.

This week I've been working on adding some features to SauSaGe - Static Site Generator (SSG) built with C++.

Issue #1: Multiple new lines add empty unclosed 'p' tags.

1. This was an issue that I knew was present in my code but I had yet to find a solution for. At the time of writing, it has been solved using an else if condition instead of an else. 2. This issue I had not thought of, since in many cases command-line applications can be executed from any location. However, without changing PATH variables (which may be too advanced for some users), this issue will remain present. So, I will have to do with simply placing a step in the instructions to execute the application directly through the command-line. 3. This issue was found to be intentional. It remains in place because it prevents .html files to be created out of sub-directory files in the initially inputted directory. 4. This issue was a little more difficult to solve without increasing the coupling of my Text module and main function. I had to resort to placing the open and closing HTML tags as a constant variable in the Text module's header file in order to reduce code repetition. 5. This issue was the similar to issue #5 that I posted on my partner's repo. Since I used a different programming language to code my application than my partner, I had to find my own solution to this issue. The fix itself was straightforward using the filesystem standard library's functions.

I just finished making my SauSaGe (Static Site Generator), excuse my idea of a "creative name".