Writing complex code that runs on multiple mush codebases can be difficult; there are parser differences (Mostly comparing Penn to the rest), function differences (Functions that exist on one or more servers and not others, or functions with the same name but different semantics), even concepts not shared by all (Zones).
This is the maybe-start of a maybe-series on these differences and ways to work around them when possible. It'll probably end up being a collaborative book or wiki section if anything more comes of it.
Now, on to the meat...
Anyone who went looking at http://download.pennmush.org/Source for the new releases might have noticed a new directory that they didn't remember seeing before.
A few days ago I put together a script to make nightly snapshots of various development branches and stow them on the download site.
The following is a rough draft of a guide that'll go up on the main web page and in a README file in the snapshots directory:
Being a brief discourse on my experiences with and opinions of various revision control systems.
I've been working on and off (Mostly off) for a while on a program that reads help files, attempts to parse them into an internal form, and then does interesting stuff with them. I'd been focusing on error-checking --- duplicate names, See also: references that don't actually exist, overlong lines, and so on.
Yesterday I sat down and added the ability to generate new help files -- both in the help format and as HTML. There's still a lot of work, especially in parsing entries and in making a nicer set of HTML pages, but you can see where it's at now here.
I've spent some time in the last few days reading up on memory management -- papers about allocator design and benchmarking. Of course, I come across papers like this one after adding a special-purpose allocator to Penn. :P
The @mail system in Penn sucks.
How does it suck? Let us count the ways.
I regularly test changes to Penn on three different computers: A 32-bit PowerPC G4 running OS X 10.4, a 64-bit UltraSPARC IIi running NetBSD 3.1, and a 64-bit Athlon64 running a Gentoo Linux that could stand to be updated. 4 different versions of gcc between the 3 (3.3.3, 3.4.6, 4.0.1, 4.1.1), though I normally only use the 4.X versions.
As part of the work for 1.8.3p3, I rewrote the info_slave process a bit.
PennMUSH is pretty well self contained. It doesn't require much in the way of external libraries beyond libc/libsystem. When it does, it's for optional things like SSL and SQL support, or for system-dependent libraries needed for networking. A customized (I removed everything not actually used) version of PCRE is part of Penn.
This maximizes ease of install -- you don't have to make sure a bunch of third-party libraries are installed (And the major issue here, as always, is Windows. I would jump for joy if we removed Windows support completely. Things would become so much easier.), but it has a cost.
I keep meaning to release universal binaries of Penn for OS X 10.4 for people who are too lazy/too slow a net connection to download Xcode and compile it themselves.
A question on the format, though: What would people want? A simple tarball, or just the directory tree in a disk image file (The standard way of releasing a single application bundle that doesn't use an installer) or a Package Installer .pkg file where it ends up prompting you for the location to copy everything into?