VerySillyMUD: Continuous Integration
Series [ VerySillyMUD ]
This post is part of my “VerySillyMUD” series, chronicling an attempt to refactor an old MUD into working condition [ 1 ]. In our last episode, we got an autotools-driven build set up, which gets us going along the path towards being able to use a continuous integration tool like Travis CI. In this episode, we’ll see if we can get it the rest of the way there. I’ll be referencing the getting started guide, the custom build instructions, and the C project instructions.VerySillyMUD: Adding Autotools
Series [ VerySillyMUD ]
This post is part of my “VerySillyMUD” series, chronicling an attempt to refactor an old MUD into working condition [ 1 ]. In our last episode, we got all the remaining compiler warnings fixed. While I was merging the pull request for it, I noticed GitHub was prompting me to get continuous integration set up. I had run across Travis CI, and knew that it was free to use for open source projects.VerySillyMUD: Fixing the Rest of the Compiler Warnings
Series [ VerySillyMUD ]
This post is part of my “VerySillyMUD” series, chronicling an attempt to refactor an old MUD into working condition [ 1 ]. In our last episode, we used unit tests to document a function’s behavior so we could refactor it to fix a security warning. Now we are able to pick up where we left off three episodes ago: fixing compiler warnings to find any gotchas. To get started, let’s re-enable the -Werror compiler flag.VerySillyMUD: Understanding a Function with Tests
Series [ VerySillyMUD ]
This post is part of my “VerySillyMUD” series, chronicling an attempt to refactor an old MUD into working condition [ 1 ]. In our last episode, we got a basic framework for unit tests in place. Just to refresh our context (and which layer of yak we are shaving at the moment): we need unit tests so we can (a) capture the current behavior of a particular function, dsearch(), so that we can (b) refactor it safely, so that we can (c) fix a compiler warning about it, so that we can (d) finish fixing all the compiler warnings in case there are other latent bugs being hidden.VerySillyMUD: Unit Tests
Series [ VerySillyMUD ]
This post is part of my “VerySillyMUD” series, chronicling an attempt to refactor an old MUD into working condition [ 1 ]. In our last episode, we encountered a function we needed to refactor: Only trouble is: we don’t have unit tests in place, and I don’t really have any idea what this function is supposed to be doing. Looks like we have to get some tests! Now, I am used to the wonderful JUnit family of unit testing frameworks, but it’s unclear which C unit testing framework to use.VerySillyMUD: Cleaning up the Warnings
Series [ VerySillyMUD ]
This post is part of my “VerySillyMUD” series, chronicling an attempt to refactor an old MUD into working condition [ 1 ]. In our last episode, we discovered a bug that the compiler had actually warned us about, but which we ignored because we were trying to just fix errors and get on with running the game. Lesson learned here; time to go clean up all those warnings. As there are a lot of them, and they are likely going to be somewhat repetitive, I will just highlight the particularly interesting ones here.VerySillyMUD: A Lesson About Compiler Warnings
Series [ VerySillyMUD ]
This post is part of my “VerySillyMUD” series, chronicling an attempt to refactor an old MUD into working condition [ 1 ]. In our last post, we managed to get the MUD executable to build, and attempted to run it, with somewhat lackluster results: Fortunately, we get a file and line number with this error, so let’s take a look: Hmm, we seem to not be able to change into whatever directory is represented by dir.VerySillyMUD: Remaining Compilation Errors
Series [ VerySillyMUD ]
This post is part of my “VerySillyMUD” series, chronicling an attempt to refactor an old MUD into working condition [ 1 ]. In this edition, we’ll try to fix all the remaining compilation errors. The next error we have is in handler.c: As before, we’ll fix this by converting it into a comment. The code clearly isn’t used, but this is an unfamiliar codebase so I don’t want to throw code away (yet).VerySillyMUD: Compilation
Series [ VerySillyMUD ]
This post is part of my “VerySillyMUD” series, chronicling an attempt to refactor an old MUD into working condition [ 1 ]. The first goal is just to get the thing to compile. The source code is early 1990s C, and I have this C compiler on my computer at home: The compiler doesn’t quite like the source code here; it generates 21 warnings and 20 errors on the first file when we run make!VerySillyMUD: An Exercise in Refactoring: Intro
Series [ VerySillyMUD ]
When I was in college, I played a MUD called SillyMUD, which was in turn a derivative of DikuMUD, which was written by Sebastian Hammer, Michael Seifert, Hans Henrik Stærfeldt, Tom Madsen, and Katja Nyboe. I happened to mention it to one of my kids, who expressed interest in seeing/playing it. I found an old source code archive of it, and it turns out it was distributed under an open source-style license Unfortunately, it doesn’t even compile as-is, and as I recall there were several scalability and memory bugs present in the codebase even when I played it.