Dumping stack traces for all interpreter threads

Occasionally, I am using someone else's code which perhaps uses threads under the hood, and deadlock occurs. When this happens, I find myself looking for code to print stack traces for each of the interpreter threads, so I can work out what is going wrong.

This Stack Overflow post serves as a good source of cut and paste solutions. The solution in question that I went with was the dumpstacks function.

In this case, I am trying to run the Python socket unit tests against the monkey patched stacklesssocket module.

Wikidot ads getting in the way of the content

The most usable site to create a free wiki, has for some time been wikidot. But I recently went back to check on a wiki I created, and I was disturbed to see the amount of ads they inject into a page. Perhaps their business model is not working as well as they would like, and in the rush to increase incoming revenue, they're ruining the content which would bring it in. Of course, my wikis are not exactly mainstream topics, so there is little point in me paying to have the ads removed.. and they would not bring in much ad revenue anyway.



I wouldn't mind such large ads, considering I am not paying them to host it, but injecting them amongst the content ruins it, and seems rather a rather underhanded thing to do. For all anyone browsing the site knows, I am the one who is harassing them with an abusive level of ads. Visiting the wiki with this much ads almost makes it seem like some kind of scam site that is one step away from installing a virus onto your computer.

A quick survey of Python MUD codebases

A few days ago, I posted in a forum wondering why there was so little packaging of MUD functionality for reuse. There wasn't much of a response, so in order to avoid spending time on other things, I decided to go through the Python code bases I could find looking for systems to potentially extract. Of course everyone has different needs and preferences, and it is good that people have made their code available. Just because I do not find anything of interest, does not mean that these codebases are not of use to anyone else. I am just evaluating these for code reuse and inspiration.

None of these codebases are ready to be picked up and have a game created on them, some are very incomplete, others simply implement some degree of logic to underly future game-related logic, and that's about it. The best candidate of the lot, for completeness and simplicity, was mudmaker. Next was bluemud, which contained much the same functionality, but in a more advanced way.

Bettermud

A multi-file MUD codebase, actually C++ and Python. I had a quick browse and failed to find any Python code. Moving on.

Last activity: 6 years ago.
License: Public domain.

bluemud

A multi-file MUD codebase. Commands are functions on a class that are manually linked in elsewhere. There is VT-100 support, used for instance in a PICO-like editor. Parsing of command syntax is done within the given command's function, and while this looks flexible, the command code unfortunately becomes complicated and unclear. Supports stacks of objects, money, NPCs, rooms, containers and more. The code is very well documented, but it is at the detriment of the accessibility of the code. The comments are aimed to be parsed out into documentation, and it shows, as they suit that at the expense of accessibility.

Last activity: 8 years ago.
License: MIT.

Bogboa

A multi-file MUD codebase. Code that would be good to extract for reuse, would be the name generation. Has basic parser, rooms, a good base of not yet functional game related code.

Last activity: 0 years ago.
License: GPL 3.

Buyasta

A multi-file MUD codebase. Code is reasonably approachable, but there is very little game-related functionality. Also weighed down by a dependency on Twisted, which it makes little purposeful use of.

Last activity: 3 years ago.
License: Modified BSD license.

DOOP: Distributed Pythonic MOO

A multi-file MUD codebase. Mostly seems to be a MOO-like codebase. Barely resembles a MUD in my opinion, especially since I was unable to find gameplay related code.

Last activity: 9 years ago.
License: GPL.

erismud

A multi-file MUD codebase. Has a database backend, where rooms, objects, users and more are persisted. Commands are hard-coded as separate methods on a class, each of which gets provided with a session and the line of input. Not much more to it than that. Data-driven, and relatively straightforward code are what I appreciated about this. No systems which look like they are worth extracting into packages.

Last activity: 2 years ago.
License: GPL 2.

Evennia

A multi-file MUD codebase. Heavy dependencies on Twisted and Django. Commands are functions in files, which are linked in by importing a global registry and locally adding an entry. This is cleaner than many other approaches, although it could be cleaner. Except for where the coupling to Twisted and Django made logic unclear, the code is relatively straightforward. Has IMC2 support that would be good to extract as a library, if it were not coupled to Twisted. Not very much game code. While this generally looks well written, it is unclear browsing through it what exactly uses what functions on objects and what they do.

Last activity: 0 years ago.
License: GPL.

grailmud

A multi-file MUD codebase. Use of decorators, which have unclear purposes and make code overly complicated. Dependency on frameworks like Twisted and Durus which add extra complication. No systems which look like they are worth extracting into packages.

Last activity: 3 years ago.
License: GPL 2.

Innerspace

No longer a MUD, but rather a .. well, something that doesn't belong on this list.

Last activity: ? years ago.
License: GPL.

Mirror Universe MUD

A multi-file MUD codebase. Very complicated code. Had a function-based command system, where commands were exported by function name in a list in the same file. The code in commands seemed almost arcane, but it would probably be interesting to take a further look into. Seemed to have OLC support and various other things, but my eyes glazed over at the complicated code, so I moved on to another codebase.

Last activity: 3 years ago.
License: GPL.

Moebius

No idea. This was too messy for me, and I gave up.

Last activity: 10 years ago.
License: ?

Python MUD Alex

A multi-file MUD codebase. Written by a kid apparently. All commands are functions on a class. Has OLC, and unlike pretty much every other codebase, actually features combat. Looks reasonably straightforward.

Last activity: 7 years ago.
License: ?

Mudmaker

A multi-file MUD codebase. Clean and straightforward code. Very simple to step in and see what purpose something serves, and guess how it is used elsewhere. Covers everything from accepting connections, zones, rooms, containers, money, clothing/wearables, tokenised messages (e.g. "$n shakes $N's hand."), building tools (OLC) and persistence. Commands are functions which are declared into a list of all the possible commands. Comes with a built game world and library of objects that while modern, serves as a great example and can easily be replaced with something to suit the desired MUD.

Last activity: 10 years ago.
License: Public domain.

mudpy

A multi-file MUD codebase. Hard to look at the source code for this MUD, as it is hosted on launchpad, which seems to be almost unusably slow from any country I use it in. Has a lot of dependencies, from both asyncore/asynchat and Twisted, and more. Had very litle game related code as far as I can tell.

Last activity: 2 years ago.
License: GPL 3.

Pantsmud

A multi-file MUD codebase. Supports advanced things like web socket connections. Dependency on Twisted adds a burden on any adopter. Code seemed overly complicated by opaque abstraction in the forms of mixins, and the way useful functionality like timing functionality was presented (i.e. the Cycle and Series classes). Seemed more like a programming exercise, than useful as either a "driver"-like base to build a MUD on and lacked the game code to be considered anything more.

Last activity: 0 years ago.
License: Apache 2.

Procrpg

One file codebase. No MUD code, no code at all almost.

Last activity: 2 years ago.
License: GPL / GPL 3.

Punymud

A very simple one file MUD codebase. Accepts a small set of commands, incoming connections are managed by their own thread and the world is defined in a serialised form as YAML. Not very interesting.

Last activity: 2 years ago.
License: Apache 2.

pyMOO

A multi-file MUD codebase. A rewrite of DOOP. Seems a bit more straightforward than DOOP, and there is some message formatting code that looks reasonably capable, but did not notice much else of interest.

Last activity: 1 year ago.
License: GPL / Python.

pyMU

A multi-file MUD codebase. Incomplete, with very little functionality implemented.

Last activity: 3 years ago.
License: GPL.

PyMUD

Almost undeveloped. Nothing to see here.

Last activity: 8 years ago.
License: GPL.

Pymudd

A multi-file MUD codebase. It seems to be written in a form which emulates how an LPMud works. Most of the code is function-based, and there are very few systems which look to of interest to extract. Mostly just seemed to resemble the driver layer of an LPMud, with no game systems. Too complicated and custom.

Last activity: 6 years ago.
License: GPL.

SchoolMUD

A multi-file MUD codebase. Dependency on Twisted for the telnet connections, relatively straightforward code but incomplete. Game code, but very little of it.

Last activity: 4 years ago.
License: GPL.

sigma-mud

A multi-file MUD codebase. Code is not too complicated, but a little arcane. Features some game code, but mostly just combat related. Movement, rooms, message formatting as well. Use of decorators adds a little confusion.

Last activity: 0 years ago.
License: GPL 2.

Simple Python MUD

A multi-file MUD codebase. Very verbose code, with too many comments, too much code doing simple things for unclear reasons. Incomplete.

Last activity: 7 years ago.
License: GPL.

slithermud

A multi-file MUD codebase. The general pattern implementation follows, is that state is held in an 'info' dictionary by any given object. Then a type of object has an array of functions that simply lookup a value by a given name in that dictionary. If you got rid of all the code that followed this pattern, the codebase would be smaller and cleaner. The comments are superfluous too. Commands are written as a class, but may as well be a function. I assume they do not require linking in, and are discovered by iterating over the relevant module contents, which is the cleanest and least burden of maintenance approach. There does not seem to be much game code in this codebase.

Last activity: 3 years ago.
License: GPL.

Sorrows MUD Framework

A multi-file MUD codebase. This is mine. It uses hidden magic to effect some of its functionality, and is not complete. While it supports objects, room, parsing and message processing, it like the other codebases is not ready to be picked up and have a game made on it. Probably way overcomplicated for your needs, and is based on a custom namespacing/code reloading system that bypasses standard Python modules and packages. In other words, has a high cost in choosing to use it.

Last activity: 0 years ago.
License: GPL 3.

tzmud

A multi-file MUD codebase. Dependencies on Twisted, ZODB and Pyparsing. Parsing looks cumbersome, making use of the Pyparsing library simply because it kind of resembles something like what you would need. Highlights that a more direct grammar driven parser is better, and clearer. Otherwise,the code is relatively straightforward to follow, although a little arcane. Magic methods are used on game objects for reaction to events, and handling other things. What context they are invoked in is unclear. If you wanted a more complex codebase that you could add your own game code to, then this wouldn't be a bad choice. But the dependencies do not seem to add much, besides dragging in more required domain knowledge.

Last activity: 0 years ago.
License: GPL 3.

Empty projects: Blackheath MUD, neokosmos, Throes MUD SERVER PROJECT.