Sean Middleditch

Off to role-play in the freezing winds and rain. Yay Michigan.

It’s supposed to snow tomorrow. Snow! It’s the bloody end of April, and it’s going to snow! And of course it has to decide to do this the weekend of KANAR, while it’s been warm and dry the last week or two. Argh!

Helped build some new structures on the KANAR field during Tuesday and Thursday evening. Apparantly many fine folks have been working out there every weekend and every Tuesday and Thursday since last event, but I didn’t find out about it until last weekend. Ah well.

The place looks a lot nicer now. I’m hoping to see even more improvements over the next year or two. Hopefully my classes at UofM starting soon won’t stop me from helping out.

bolsh: I can send you a snapshot of Wikisome. I use it just as you describe on a personal server. It’s very simple and easy, and the authentication system was designed to plug into whatever existing system you have, including things like Apache authentication. My system at home use mod_auth_negotiate to authenticate users against the local Kerberos realm, and the Wikisome setup uses maybe 10 lines of code at most to pull my name and stuff out of /etc/passwd after checking who Apache authenticated the user as.

Also includes simple ACLs so you can let other people view your wiki, or just parts of your wiki, comment on certain parts, whatever you need.

I don’t have the code packaged up anywhere since Sourceforge rejected the project (apparantly my paragraph long description wasn’t clear enough for whoever reviewed the project), but I can send you a tarball and some simple instructions if you want.

I’ve been working on Scriptix2 some more again. I still stand by original statement that it would only take a couple of weeks to get done. What I didn’t say is that those couple of weeks worth of work would be spread over half a year. ;-)

So far as Scriptix1 (or Scriptix0, I guess you could call it), I made the mistake of getting in the trap of, “Oh, I can improve it a little, make it a little closer to what Scriptix2 will be like…” Yeah. Week down the drain there. (That week was also spread over many months.)

I’m currently thinking of pulling Scriptix1 into AweMUD. Nobody else is actually using Scriptix, and if they are, I pity them. ;-) Having Scriptix be a separate library just means that AweMUD can’t integrate as well. So right now I’m trimming tons of cruft from Scriptix that was there only because Scriptix was supposed to be general purpose, and then I can see about just dropping Scriptix in the AweMUD source tree and combining a bunch of redundant code.

While I’m at it, I might just drop the GC library into the AweMUD source tree so that people have an easier time compiling AweMUD.

It’s been about a year since my last Mountain Dew. Yay me!

Now I’m working on cutting out my current Dew-replacement, which are several brands of energy drinks. My current favorite is the lo-carb Monster drink. (The non lo-carb version is too sweet.) Although this drink really isn’t all that unhealthy, at least compared to a Dew, it still does have stomach-destroying carbonation and caffiene.

They also cost $2.50us a can, and I’m known to drink three cans a day. Two cans if supply is low, which tends to be the case because half the stores near where I live cannot keep anything in stock (they must be trying to go out of business or something) and the others just don’t carry the drink I like.

Since there’s a current supply shortage, I decided to not drive around town trying to find more, and instead rought it. Then I decided to just use this as a good excuse to quit drinking them. That gets rid of the health problems they can cause, plus saves me over $200/month. Two-hundred dollars per month!!

It’s been all of three days, but let’s see how this goes. Once the head-aches and constant fatigue pass from the caffiene addiction being broken, I should be in the clear. After that it’ll just be some junk food that I need to cut out, or at least reduce. For example, cereal. Cereal makes a fine breakfast. When we have cereal, though, I tend to turn it into breakfast, half of lunch, after-work snack, and late-night snack. I usually miss at least one of those day, so it turns into three (big) bowls of cereal per day. Sugary yummy Captain Crunch Peanut Butter cereal. That’s not healthy to eat that many bowls (although it’s certainly cheap enough, unlike the energy drinks), so I need to cut it out. The easiest way is to just stop buying cereal and find a different breakfast, but I can’t stop cereal from appearing in my house, mostly because the other three familiy members eat it as well.

I’ll worry about solving the energy drink problem first, and then see about the cereal and the other few sweets I eat too often. Cutting out the energy drinks alone will probably make me one of the most vice-free people I know. ;-)

Since I seem to have forgotten to tell a wide number of people, I’ll just announce it here:

I’ve been accepted into the University of Michigan.

What’s the reasoning behind using wide (16-bit) characters in Java(tm), the CLR, and so on? Was there some particular problem with UTF-8 encoding, did the designers just not think about it, or was there some other reason to pick 16-bit?

I know in most code it probably doesn’t make a difference, but I’m running into some trouble with it. Namely, most network protocols are ASCII based, maybe UTF-8 compatible, but definitely not friendly to 16-bit encodings. So I constantly have to convert back and forth, which is less than stellar in my opinion. Certainly something I can live with.

Just wondering why those runtimes went down the 16-bit path.

I started a small project called libtelnet. I’ve gotten completely fed up with the piss-poor implementations of telnet in most MUD servers and clients. They’re generally crap. The coders have no idea how to deal with the network (telnet commands and such are _not_ guaranteed to arrive whole), no idea how to deal with telnet itself (doing byte-range comparisons with the telnet commands you know will not result in code able to gracefully handle the ones you do not know), and don’t even seem to understand the basic problems when told about the bugs. “It works for me…”

Exasperating.

Libtelnet is a pretty simple C-based (for now) library. I’m going with C because that’s what most MUDs are written in. If requested, I’ll try to port it to other languages. Java is relatively popular for MUDs these days, so a Java version seems likely. A C++ version would also be nice. There are almost no C#/CLR MUDs around (though I started another mini project just to see how hard it would be to write one), but I might do a port there to. Any other languages I’ve missed I’m open to porting to if there’s need. The library will be fully maintained to the best of my ability (which isn’t a lot of effort - it’s a tiny protocol handlign library, maybe a thousand or two lines of code at most when done, which isn’t much at all for C).

It’s got a stream-based design. You allocate the object and associate it with some user data and a vtable of function pointers for handling telnet events. As you receive data from the network you pass it into the stream, and when whole bits come through they get passed on to your vtable functions.

While I’m at it, I’m going to drop in ZMP support, so any code using it gets a ZMP framework for free. Not like ZMP support takes a lot of code - I designed it not to, after all. ;-)

The only other non-core-telnet feature I’d like to get in is MCCP/zlib support, just because that sorta belongs at this layer.

I’m tempted to build a multi-layered affair that makes all sorts of plugins and such possible, and make ZMP and MCCP support plugins and such, but I think that would just be over-engineering. Especially if I’m going to commit to professional-level maintenance, I need to keep the code simple.

Once libtelnet is done, I’m tempted to write a few other simple libraries for things MUDs get wrong. One is event loop processing. There are several great event loop libraries out there, but they all are either far too heavy weight or far to over-specialized. All a MUD really needs is an ability to list sockets (file descriptors) to poll and timers.

Writing such a library for Java or C# would be even more useful than C, since C has a ton of such loops to use and Java and C# have none; they rely mostly on threads, which is not a robust solution in my opinion. Threads making programming simple code far more difficult than it should be.

Unfortuantely, in the case of Java, only newer JVMs/class libraries could even support such a main loop framework, since there aren’t any low-level APIs that can support such a framework with the java.nio package. ::sigh::

I really should be working on D-VFS or a contract job instead, but my give-a-shit meter is just too low. Telnet is striking my fancy right now, so that’ what I’ll work on. ;-)

Why do I get the feeling that Havoc is talking about me (among others) here:

For the record, I don’t think the current round of D-Conf discussion will go anywhere, because a number of the people involved are known to be more about sending mail than writing software,

Yeah, that sounds a lot like me in certain circles (the FDo circle definitely being one of them). I actually noticed this a while ago. I don’t write much software anymore. Not outside of the things I do for pay, which tend to be less of writing software and more of gluing software together in some script language or another.

The good news is, I’m pretty sure I know why I don’t write much software anymore.

It isn’t fun.

I don’t mean to say that developing software is not fun. That’s a blast. Getting something working is even more fun. Getting something great working is the best. But the actual writing of the software itself is, quite frankly, as unfun as it gets.

I’ve come to the conclusion that the problem is largely a problem with the development tools I use. Most of the kinds of software that I enjoy developing are low-level things. Making a graphical music player application holds no interest to me. Making a graphical toolkit is something I would have a blast doing. I don’t like living at the really low levels, like kernels and drivers and raw-to-the-metal sorts of libraries, but more of the framework code that the rest of the world sits on top of. Writing that kind of software is relentlessly complex.

There is no lack of good development tools. I’ve written utilities, apps, and even libraries in “hip” languages. Like Python. And it was good. Fun, even. Only, for those apps that I generally like to work on, I’m not really allowed to use Python. Or even a CLR language. Or Java. I’d be lucky if I get away with using C++. (I envy the KDE developers. I’m a fan of the GNOME user experience, but hold much greater love for the KDE development framework.)

When you’re writing a library to be used by countless applications written in countless languages, when you’re writing a daemon or service that is going to be running on a wide variety of machines by a wide variety of people, this little thing called politics gets in the way. Sometimes there are technical issues, yes, but vastly more often than not, someone has a beef with some tool or solution based purely on FUD.

Let’s take D-VFS for an example. It’s something I really want to get done. But even getting started on real code is such a burden. All because I have no choice but to implement it in C. Maybe C++. Either way, I am going to end up spending hour upon hour writing code that I have, honestly, all ready written before, just getting a basic framework in place. Sure, sure, there are tons of great basic frameworks I could start with, like glib, but as soon as you add a dependency you get just as many people screaming and fighting as if you used a language that needs a runtime. (Which is of course a dependency.)

Someone familiar with C# could probably slap together a fully functional D-VFS prototype in a few days. I’m fairly tempted to do so, except that I know it won’t ever be really accepted (being a prototype no less) and if I write it once in C# I’ll be even less favorable towards rewriting it again in C.

This kind of anti-dependency/anti-language FUD really needs to end. Is it performance people are worried about? My phone has a freakin’ JVM in it. If my phone can run Java(tm) at fully acceptable speeds, I think your desktop machine could handle it just fine. Or any other interpreted (or maybe even machine compiled!) language that has a runtime dependency.

So how come I’m not allowed to use one?

I have finally written the Web-based MUD Client I’ve been wanting to do for a long while now. Or, at least, I’ve started on it. And got it fairly well working, even.

The trick was getting the network connection. JavaScript can’t do that, not without Gecko extensions, and in the Real World(tm) the majority of users don’t use Firefox. Since the whole point of a web-based MUD client is to make it possible for just about anyone to use it (and also a little that making flashy UI-type stuff in HTML/JavaScript is a lot easier than in GTK/C), making it widely usable was a priority. Thus a Java(tm) applet.

The applet still needs work. It doesn’t really do much with the telnet options, although it does understand them enough to not spit them out to the display. It does actually connect to the MUD server and talk to it (using threads - who over at Sun thought that bright one up? “let’s make it so that you need a bazillion threads to simulate a simple select() loop!”) and does interface with JavaScript using the Java/JavaScript bridge called LiveConnect! by Netscape, and hopefully called something by Microsoft because I’m going to be pretty sad if I find out it doesn’t work in IE.

Although at this point I wouldn’t be surprised if it didn’t work in IE, merely because I haven’t tested it there and there’s plenty of room for bugs at this point. There are a few I know of already, but won’t fix just yet.

One thing I’m very pleased with is the speed and display quality of the client as a whole. There are several Java(tm) applet MUD/telnet clients around, and they all suffer from very poor text rendering both in terms of speed and quality. Probably something to do with being limited to the (supposedly?) slow AWT toolkit. My client spits all the display out as HTML into a div tag using JavaScript, so it looks as pretty as any other text on any other website. The speed is actually rather surprising. The bridge between the JVM and browser isn’t exactly speedy, but it seems to display output faster than the AWT-based applets I’ve seen.

Speaking of speed, I already did some “early” optimization. That bridge was indeed causing some speed problems originally whenever an ANSI color code came in. Upon seeing the ANSI code, the parser would dump all the text it had so far, parse the ANSI code, dump the result, then resume with the text. Any portions of output that had a lot of color codes (like the big banner/logo in the AweMUD login and menu screens, were just dog slow to display. I optimized by simply buffering up all the output and flushing it one go after an update. That means there’s generally only one bridged call per output update (for non-overly-large updates), which is more than fast enough.

Now that I’ve got the basics working on the JavaScript side, I’m thinking about finding a decent JavaScript widget library (I think the Novell/Ximian guys were recommending one not long ago, will have to look into it) so I can make the UI real nice-like. It’s just a text input field right now, and that just won’t cut it. Oh no, definitely not. ;-)

Also need to recruit some artistically talented types to make the pretties for the interface. Give it a decent fantasy game atmospheric look. Something like Simutronics’ StormFront client, only not bloated beyond usefulness and Windows-only.