ZetaMUCK
I had a brief stint as a ProtoMUCK developer during the last few years. ichijo_akari had given me commit access a long time ago so that I could modify scripts and improve documentation here and there, but after I stepped down from MotM I decided that I was interested in a little more than that.
If you're a Unix admin for any amount of time, you're exposed to source code. It's a matter of necessity, as CPU architectures and library versions are much more divergent than in Windows land. (you end up compiling a good amount of code instead of downloading binaries) I had enough knowledge to be dangerous, and started fixing a bug here and there. Then I decided to extend things (PCRE regex support), and finally work on some features of my own. Fortunately Akari was able to provide some guidance now and then, which helped shape some good practices and prevented me from being an anathema to the codebase in general.
That said, I stepped down from ProtoMUCK a little over a year ago due to some philosophical differences with the active maintainers. (Akari isn't one of the active devs, so don't ask her about this) I forked the codebase and continued to work on it, mostly for my own purposes. I wasn't sure at the time whether I'd make enough changes to warrant actually announcing it, but I think it's come far enough to where it's worth sharing. I went with ZetaMUCK because I suck at names.
You can find the source here:
https://code.google.com/p/zetamuck
(right now you have to do a subversion checkout, if enough interest is expressed I'll start doing tar.gz uploads)
Edit: Turns out I had documented pinned arrays better than I remembered. I've added them to the main change list.
New features
256 color support
Akari added this to Proto awhile back and you're probably not aware of it. Color is awesome and everyone loves it, so it gets the #1 spot of this list anyway. "help 256color" for details.
Support for PCRE regular expressions
I backported this from FBMUCK to Proto awhile back but I don't expect many to have noticed. This replaces the old non-PCRE regex support. There are a number of extensions beyond the original FBMUCK code, such as additional prims and predictive optimization. (something PCRE calls "studying") Requires PCRE headers, and automatically compiled in if they can be detected at build time. "man regex prims" for details.
Built-in player @aliasing
Something else I added to ProtoMUCK awhile back. See "help @alias" and "man @alias" for the implementation details.
Support for JSON encoding and encoding
Requires the libjansson headers to compile. Not automatically built in. "man json prims" for details.
JSON integration with the built-in webserver
If JSON support is compiled in and the content type of a POST is "application/json", the JSON payload will be deserialized to objects on the MUF stack. This theoretically opens the door to some really ninja AJAX stuff.
Preliminary support for HTTP/1.1 persistence
It's now possible to process more than one request per HTTP connection. That said, HTTP/1.1 pipelining is still a work in progress...so don't try to take advantage of this just yet. I'll try to have this feature completed sometime before the end of the year.
Each connection to the game now has its own encoding
This is kinda complicated; some of you may have heard about "extended ASCII/Latin1" or "Unicode/UTF-8". These are called character sets. ASCII defines 7 bits worth of characters, but leaves the 8th bit undefined. Latin1 and UTF-8 do completely different things with that bit, so without being able to tell the game what you support, there's no telling what you're going to see on your screen when someone pastes those characters into the game.
tl;dr, tune @ascii_descrs to true and it's assumed that all clients only want to see standard ASCII unless their MU client negotiates otherwise. This is called the "ASCII" encoding. If this @tune is not set, the game assumes that all connections are a "RAW" encoding, which is the traditional behavior. This will let everyone see the extended Latin1 characters, at the price of seeing garbage whenever someone pastes in UTF-8 bytes.
There's also an @encoding command for manually switching your current connection between encodings, but I see I didn't get around to documenting that. Whoops. :( I'll try to fix that in the near future.
Pinned arrays
Backported from FBMUCK. Normally, changing an array on the stack causes the array to be "decoupled" from all other copies of that array in memory. This makes it so that modifying the array doesn't modify all other copies of that same array.
Pinning an array returns a new version of the array that is not subject to decoupling. If you pin an array, duplicate the pinned array, and change the duplicated array...you'll also change the array you duplicated it from. This includes copies of the array stored in a variable. Practical upshot: if you store a pinned array in a variable, you don't have to store the modified array back in the variable after changing it.
Pinned arrays violate the stack expectations of most coders, and should be avoided unless you're working with extremely large arrays in memory. (buffers, rotating lists, etc.)
"man array_pin", "man array_unpin", "man pinned?" to see how they work. PINNED? is a ZetaMUCK extension.
Reworked build scripts
Unless you actually make changes to the code, you don't care about this.
Misc
* Fixed a few memory leaks and uses of uninitialized memory with the help of Valgrind. Many of these are ancient and have been around for quite some time.
* I've moved away from using the custom memory profiling code in favor of Valgrind's. It notices much more than just memory leaks. Any messages reported by Valgrind are considered a bug. There is an exceptions file (valgrind.supp) for suppressing certain warnings that aren't truly bugs per se.
* Some low level optimizations in combining strings. I doubt anyone will notice the improvement unless they're doing some serious file or network I/O.
* pmatch no longer returns #-2 when a user is logged in multiple times. (at Akari's request, so she can stop hating life)
* I tried to implement UTF-8 in ProtoMUCK awhile back but this code should be considered unsupported until I've had a chance to revisit the implementation. There are a few things I want to do differently.
If you're a Unix admin for any amount of time, you're exposed to source code. It's a matter of necessity, as CPU architectures and library versions are much more divergent than in Windows land. (you end up compiling a good amount of code instead of downloading binaries) I had enough knowledge to be dangerous, and started fixing a bug here and there. Then I decided to extend things (PCRE regex support), and finally work on some features of my own. Fortunately Akari was able to provide some guidance now and then, which helped shape some good practices and prevented me from being an anathema to the codebase in general.
That said, I stepped down from ProtoMUCK a little over a year ago due to some philosophical differences with the active maintainers. (Akari isn't one of the active devs, so don't ask her about this) I forked the codebase and continued to work on it, mostly for my own purposes. I wasn't sure at the time whether I'd make enough changes to warrant actually announcing it, but I think it's come far enough to where it's worth sharing. I went with ZetaMUCK because I suck at names.
You can find the source here:
https://code.google.com/p/zetamuck
(right now you have to do a subversion checkout, if enough interest is expressed I'll start doing tar.gz uploads)
Edit: Turns out I had documented pinned arrays better than I remembered. I've added them to the main change list.
New features
256 color support
Akari added this to Proto awhile back and you're probably not aware of it. Color is awesome and everyone loves it, so it gets the #1 spot of this list anyway. "help 256color" for details.
Support for PCRE regular expressions
I backported this from FBMUCK to Proto awhile back but I don't expect many to have noticed. This replaces the old non-PCRE regex support. There are a number of extensions beyond the original FBMUCK code, such as additional prims and predictive optimization. (something PCRE calls "studying") Requires PCRE headers, and automatically compiled in if they can be detected at build time. "man regex prims" for details.
Built-in player @aliasing
Something else I added to ProtoMUCK awhile back. See "help @alias" and "man @alias" for the implementation details.
Support for JSON encoding and encoding
Requires the libjansson headers to compile. Not automatically built in. "man json prims" for details.
JSON integration with the built-in webserver
If JSON support is compiled in and the content type of a POST is "application/json", the JSON payload will be deserialized to objects on the MUF stack. This theoretically opens the door to some really ninja AJAX stuff.
Preliminary support for HTTP/1.1 persistence
It's now possible to process more than one request per HTTP connection. That said, HTTP/1.1 pipelining is still a work in progress...so don't try to take advantage of this just yet. I'll try to have this feature completed sometime before the end of the year.
Each connection to the game now has its own encoding
This is kinda complicated; some of you may have heard about "extended ASCII/Latin1" or "Unicode/UTF-8". These are called character sets. ASCII defines 7 bits worth of characters, but leaves the 8th bit undefined. Latin1 and UTF-8 do completely different things with that bit, so without being able to tell the game what you support, there's no telling what you're going to see on your screen when someone pastes those characters into the game.
tl;dr, tune @ascii_descrs to true and it's assumed that all clients only want to see standard ASCII unless their MU client negotiates otherwise. This is called the "ASCII" encoding. If this @tune is not set, the game assumes that all connections are a "RAW" encoding, which is the traditional behavior. This will let everyone see the extended Latin1 characters, at the price of seeing garbage whenever someone pastes in UTF-8 bytes.
There's also an @encoding command for manually switching your current connection between encodings, but I see I didn't get around to documenting that. Whoops. :( I'll try to fix that in the near future.
Pinned arrays
Backported from FBMUCK. Normally, changing an array on the stack causes the array to be "decoupled" from all other copies of that array in memory. This makes it so that modifying the array doesn't modify all other copies of that same array.
Pinning an array returns a new version of the array that is not subject to decoupling. If you pin an array, duplicate the pinned array, and change the duplicated array...you'll also change the array you duplicated it from. This includes copies of the array stored in a variable. Practical upshot: if you store a pinned array in a variable, you don't have to store the modified array back in the variable after changing it.
Pinned arrays violate the stack expectations of most coders, and should be avoided unless you're working with extremely large arrays in memory. (buffers, rotating lists, etc.)
"man array_pin", "man array_unpin", "man pinned?" to see how they work. PINNED? is a ZetaMUCK extension.
Reworked build scripts
Unless you actually make changes to the code, you don't care about this.
Misc
* Fixed a few memory leaks and uses of uninitialized memory with the help of Valgrind. Many of these are ancient and have been around for quite some time.
* I've moved away from using the custom memory profiling code in favor of Valgrind's. It notices much more than just memory leaks. Any messages reported by Valgrind are considered a bug. There is an exceptions file (valgrind.supp) for suppressing certain warnings that aren't truly bugs per se.
* Some low level optimizations in combining strings. I doubt anyone will notice the improvement unless they're doing some serious file or network I/O.
* pmatch no longer returns #-2 when a user is logged in multiple times. (at Akari's request, so she can stop hating life)
* I tried to implement UTF-8 in ProtoMUCK awhile back but this code should be considered unsupported until I've had a chance to revisit the implementation. There are a few things I want to do differently.