Category: Common Lisp

Programming and assorted nonsense

LunaMech has been converted to LMAV2.


19th of January 2022 at 03:12am SAST

I finally sat down and took the time to convert LunaMech over to the second version of my Matrix API. The conversion process did not take as long as I had expected. At the same time I converted my Matrix API library to parse JSON as a hash-table rather than as a plist (this is both faster and more secure and so it would be nice if Jonathans default behaviour was this...), anyway the conversion process was made quite easy because I had used a macro which I had called 'pkv' to access plist values from parsed JSON, by simply changing the definition of PKV to access a hash-table instead much of the conversion was done automatically, the rest of the conversion was adding a few missing features, changing instances of getf to 'get-key' and testing repeatedly.

Since the conversion has been complete LunaMech has experienced 0 downtime.

Ofcourse I have not updated the documentation so LunaMech is effectively totally unusable to the uninitiated despite the fact that Luna makes Matrix very usable... Oh well.

LunaMech is finally FOSS software

Source and website.

26th of August 2021 at 15:30pm SAST

I have finally taken the time to extract all the hardcoded private keys and place them in a persistent library, meaning I am able to make LunaMech FOSS. LunaMech has been running on the scyldings.com Matrix server for close to a year now and has been under constant active development. It will remain under constant active development into the future as well. As of the time of writing this entry the bot will not build from source because I wrote a new macro called 'defmodule' to wrap up the process of defining new modules, but this does not play nicely with the compiler by default which I have to fix at some point, I may even change the abstraction to a metaclass... I am not sure yet.

Right now there is only an outdated way to generate a functioning config file, obviously this code base has been in active development so I have been using a config file that was generated many moons ago and I have slowly adapted it to work with any incremental changes, but this does mean that the config generator is out of date. The documentation in the README is also out of date, regardless it does provide a general overview of the default features of the bot, that being said the fundamental design idea of communities is almost outdated now that Matrix Spaces are making solid progress.

There was some more up to date documentation that was hosted on a taiga instance, however this instance is gone and I no longer have the documentation so I will have to go through and make some new documentation.

Let me briefly explain Luna's functionality right now:

The core idea of Luna are 'communities' these are mappings of room ids to room names which maintain a list of all of the members within them and their administrators. Commands like 'ban' will ban a user from all of the rooms listed in the community, ofcourse this is becoming less relevant as Spaces progresses, however this is still in heavy use on our Homeserver, the same goes for invite. Invite is especially useful if you want invite only communities.

Luna maintains a list of communities with a file called 'communities.lisp' in a directory called config/, all persistent files for modules is also stored in this directory. The file communities.lisp is backed up roughly every 5 minutes, because Luna is effectively a naturally evolving program that was both the prototype and the product I still think that use the filesystem for persistence of the main file is a decent solution, although I could swap to Bknr.

Luna grabs messages for every 'listening-room' listed in each community and processes those messages, messages that start with '.' are assumed to be commands, however a completed command is something like '.<community-name>|<module name> <command-name> <args>', commands for modules are also invoked from within a community listening room. Once the prefix is checked the correct command is found within the global *commands* and invoked with the the arguments provided by the user. If the command is missing then its passed off to the default missing command generic which will decide whether to tell the user or not depending on their privilege.

After processing all of the messages for all of the communities and executing the functions as it should, Luna maps through all of the registered modules and hands the instance of the bot and the current sync object (I say object but its actually a list) off onto a method called 'on-sync' which every module is able to specialize, this is where much of the automatic functionality of Luna is found, because each module is able to perform actions based on the information in the sync object.

After doing this a few thousand times methods like 'on-save' are invoked so that modules can save themselves to whatever their persistent storage mechanism is, communities.lisp is also backed up.

Modules can be loaded and unloaded from Luna on the fly, loading invoked on-load-up, unloading on-module-unload. This is done either within your connected Sly session or using Lunas command invocation system.

This basic model is how all of the current functionality of Luna is implemented. Ofcourse this may change.

Anyway, hopefully I will get the time to write some developer docs and update the readme, I will host them on LunaMechs website.

Updates regarding Luna will be posted here for the foreseeable future.

An introduction to CL-BLOGGY

Blogging with CL-BLOGGY

22nd of August 2021 at 01:12am SAST

Okay, lets write an introduction to how you setup and use cl-bloggy.


CL-BLOGGY is a Common Lisp library that allows you to live code entries into your blog. It is designed to be highly extensible; the majority of the functionality has been implemented using Generic Functions, this means that as a user you can customize the behaviour of most of the system, although I imagine you would primarily be interested in customizing its appearance. By utilizing the CLOS I have created a webpage generator that allows the user to fully customize the appearance and the layout of their own blog. By writing a Lisp form you are able to produce a nicely formatted and ready to go blog post in your own instance of CL-BLOGGY.
At the time of writing this library handles the following:
List of cool things:
  1. Creation of blog posts.
  2. Deletion of blog posts.
  3. Direct links to posts (obviously)
  4. Ordering of posts by date.
  5. Ordering by date within an index.
  6. Ordering of posts by categories
  7. Nesting of categories, ie each category is a child of the former 'general <- programming <- common lisp <- cl-bloggy', a category can only have one parent but many children
  8. Creation of a primary RSS feed at (format stream "~A/rss.xml" (url (blog <acceptor>))
  9. Creation of category based RSS feeds at (format stream "~A/~A/rss.xml" (url (blog <acceptor)) (url category))
  10. Customizing the layout of the blog, entry and index using generic functions.
  11. Minimalist CSS, currently 3 external style sheets are imported by default: milligram.io, normalize.css, and Google's Roboto font (required for Milligram)
  12. Customizing the colour scheme of the blog, entry and index using generic functions.
  13. A simple 4 palette colour scheme using both CSS and Common Lisp global variables for easy theming
  14. Sane but currently as of the date of this article, changing default CSS.


The goal of the library is to allow a Common Lisp user to setup their own blog, on their own VPS where they can create and manage entries with ease. It's designed to be highly extensible, what is the point writing it in CL if it isn't built this way? It is designed to be open to the programmer, each object in the system has access to the others, even the instances of blog instantiated for rendering categories are aware of the top level blog. The library has been designed this way because it allows an experienced Lisper to customize the blogging system however they want. The code should also be easyish to understand, I know that every Lisp programmer has their own programming style, but my intention with this library is for it to be reasonably readable with minimal use of macros, so code readability over macrology
Programs must be written for people to read, and only incidentally for machines to execute. - Abelson & Sussman, in the preface to the first edition of SICP.