Back

Plugins, Lua, Alvu

Now, this was going to go into kb but would better serve as a proper post so let's get to it.

Plugins

Most people might already know what plugins are but for those who don't , it's a mechanism to extend the original implementation with additional features / mechanisms / etc etc.

Being able to write a truly open API for the plugins to use is pretty hard to do and could end up being complicated and finding languages that most writers could easily learn and use is also a challenge.

Not everything needs plugins but it definitely takes the load off of the developer to develop and add everything into the tool/app/whatever.

I assume most readers are coders so you already know all this and the closest example would be your code editor, either sublime, vs code, vim whatever, there's plugins everywhere.

Next, moving onto the reasons to choose lua as a language and things I learned.

Lua

I barely knew about the existence of lua since I've heard of it being the embedded scripting language for most platforms (games, micro hardware, etc) but never really learned it.

I recently started moving to nvim from vscode and lua was the choice of configuration by a friend and I'm using his configuration so I just stuck with it.

Basically, started learning lua to soon realise that the language is pretty tiny, easy to remember and very easy to read even in larger codebases.

It's simple to extend with other functionalities by just adding additional .lua files to your project and importing them into your code, or you can use the global system level libraries with luarocks which can involve having libraries writing C lang code that builds into lua.

Thus, the language can be easily extended.

Now, choosing it for alvu was a no-brainer cause alvu itself barely has any functionality. The entire codebase is like 500 lines in a single main.go right now .

It just takes in a directory, converts it to html, everything else is done by the developer and that sounds like a pain but let me tell you what the developer actually does.

As a user of alvu, you will rarely every write the entire functionality of the blog / wiki / static site that you are building. You'll mostly just bring in content.

Everything else is already going to exist as a template for you to use, alvu is just a tool that knows how to process these templates for you. This gives us a way to keep the base tool tiny and still infinitely extendable and considering how small the Lua VM is extending it is not that hard.

Alvu

You might already know what it is, or you might not, to be put in single statement.

Alvu is a static site generation engine which can be extended with plugins written in lua.

We call these plugins hooks but basically they are the primary drivers of how things post render will look.

The base idea is implemented but it's going to change over time with the lua hooks taking over the entire functionality of alvu and the only thing alvu would be doing would be to give the hooks information about what to process.

Now, this also does shape the direction for other tools that I have and where needed there will be ways to extend the tools (while keeping the base tool as tiny as possible)

Problems

There's never anything without it's own set of problems so here's the things that were causing issues when working with it and how I wish I could improve perfs

  1. I was unable to setup a waiting queue algorithm without making the program overly large and so I had to give up on that algo altogether. (preferrably build it as a package for later use)
  2. Right now it uses a combination of channels and mutex ( exclusion locks ) which internally depend on channels and this code could get messy very quick, and I did actually get it to be a little more complex to read so you might wanna avoid that when working with Lua VM since it's not directly thread safe and you can have one lua state instance per go routine.
  3. There's quite a few repetitive tasks that a alvu template developer might have to do which while isn't a problem that can't be easily solved, it is a problem as of right now and don't just go on promises I'm making.
  4. Lua as a language does have it's own shortcomings, no regex support, string manipulations are limited, etc etc. And while I can extend lua to have these features, it will increase the size of the original tool and that's something we are trying to avoid so it's considered a problem.

Well, that's about it for the post. Adios!