Exploring a 23 years old code base: LambdaMoo MUD Part 1

On these days my greek daemon (the one which talk to me about deep nerd programming) was interested on LambdaMoo.

LambdaMoo is an Object Oriented Multi User Dungeon born back in 1995. A MUD was a text based system you log in, talk with other, create adventures and so on. LambdaMoo has a script language and the entrire system could be customized.

The LambdaMoo last version 1.8.3 was a work in progress in 2008. LambdaMoo today is 23 years old.

So my daemon asked me: if you were able to do a  tech refresh of LambdaMoo, waht will you eventually suggest?

To respond to this question, I need to study the original code

LambdaMoo: The System

A lot of links are dead and finding out updated documentation is a dauting task: I was able to find a 1997 programmers Manual, and some FAQs along the way. LambdaMOO source code examples are a bit difficult to find: I suspect they live in database dumps (see below).

LambdaMoo is composed of a object database, dumped to a text file. Then there is the MOO programming language, an object oriented, single-inheritance programming language with a very basic syntax.

The LambdaMoo provide you with minimal editing capabilities to write code, describe rooms and so on.

The server seems a multi-connection single thread server, which schedule tasks like an operating system will do.

The server forks only to do a database backup, which is a smart way to do things. You got for free a freezed copy of the memory, at risk of doubling memory usage (anyway modern operating systems does copy-on-write, so memory consumption on Linux is manageable  if the server did not got much activity during the dump).

The Core Database

The core database is a 2264kb (!) database.  The entire systems can work with little as 14MB of RAM (split in three processes linked together).

The source

Lambdamoo source is composed of about 31895 lines of code split in 58 C files. The code base is very well commented. Via etags I was able to navigate it in emacs without problems.

It is remarkable how a 23 years code runs smooth on a RaspberryPI ARM linux and compiles without issues on a different architecture.

Dependency are limited to yacc parser.

Also some macro to emulate try..catch..finally are implemented via longjump() ANSI C.

How will you reimplement LambdaMOO today?

Some basic consideration

1. LambdaMOO is a single thread application. It does not seems to support federation or an easy way to export database. Object Oriented database seems difficult to migrate from one instance to another.
2. The database is RAM based. It is very compact and optimized (it is hardcore C after all) but it is limited to available RAM. With a 2MB database, a 1GB RAM space seems a quite big room to fill
3. The language is interpreted, so its speed is limited. Some good candiates are LuaJIT or Python (for codebase) Lua is C-pure and very easy to integrate, easier then Python.
4. Lack of documentation.

After some research I choose a fork called "gammamoo", with a good set of bugifxes and forked it.

The code base here is < 35000 lines, a bit more but still manageable.

 

https://github.com/daitangio/gammamoo

 

Small optimizations (step by step)

The first idea was to add a library for memory leak detection,only  to avoid putting bugs on the MOO code base. Huble programmer is a winner.

So if you plan to modfy the code, fire gcc at maximum warning level and lets' start!

Sqlite Revenge

My first attempt was to introduce sqlite3 instead of the memory-based database. Lambdamoo database is based on object identifer (oid) which are indexes on a big array called objects. My first attept was to make a new version of the database dump in a sqlite3 format. The idea is to write the data in a SQL structured way. I chosed sqlite because it is C-based, it can be obtained as a single C file, and have very few dependency (only on dynamic linker if you omit the pthread part). Also sqlite can run optionally in memory, so if you have a small databse you can read a core database and run in memory. Benefits: you can have very large database stored on disk. Main challenge: because the code is memory-based, even if the object API is well written and isolated, a lot of code write directory into object structure and did not pass via a API. All this code must be changed to use a "gateway" API to make the change persistent, at least in theory.

 

 

 

Last words

LambdaMoo is still availbale at lambda.moo.mud.org port 8888 via telnet. It runs "Running Version 1.8.3+47 of LambdaMOO".

I got 46 guys there: very little indeed.

A deep customized version was done in Milan, called Little Italy, and died around 2000.

This page is a good starting point for more information on LambdaMoo

The original source code is mantained here

https://github.com/wrog/lambdamoo