The OpenEmbedded/OpenZaurus folks released 3.5.2 today. I flashed with the new image and it's pretty cool, though I don't notice any differences. Mostly I just flashed and pressed a bunch of buttons and then shut it off.

I need to get a case before I really want to bring it around with me. I'm still paranoid that I'm going to break it while using it. I need to get a wireless card or figure out how to sync with the docking station or something similar so I can back up my information.

A month ago, my girlfriend and I wrote a children's book about a bee who gets stuck. It was pretty wild writing it--I had most of the process down before I met her, but she definitely filled in the pieces I hadn't figured my way through yet. It was really great--we were a great team. Anyhow, so last week we finished moving the book over to PDF format, printed a copy on the color printer downstairs, and gave it to my friend to give to his daughter. Turns out she really liked it--which is really great! And she wrote us a thank you note which was really really neat!

We enjoyed writing the book. We especially enjoy the fact that someone enjoyed it.

I gave my desktop to my girlfriend's parents because their machine was about to die (like, serious death) and my machine was more machine than I needed and I figured I'd borrow some spare components from my dad and after that series of transactions, everyone would be happy. Thus it transpired and everyone was happy! w00t!

Then I discovered I couldn't put the massive full tower case under either of my desks and with the fourteen fans (some of which were parts taken from dismantled B-52 flying fortresses) it sounded like my desk was sitting on the tarmac of an air field during an air show.

Not to look a gift horse in the mouth, I decided to get a smaller quieter case and picked up an Antec Sonata. It's great. Everything I had read about it was right on down to the fact that you can count exactly how many times you touched the top of the case due to the amazing ability of the piano black finish to preserve in a pristine fashion every single detail of every single fingerprint.

Then after wrestling with the IDE ribbon cables, I decided to pick up two rounded IDE cables for $8.00 each.

The machine is super duper! Total monetary cost to me so far is $112. My girlfriend's parents got a machine to replace their very seriously almost dead one. My dad freed up some room in his computer room. Everyone is happy!...

Well, except for my girlfriend who's a little unexcited when I spend long periods of time over several days futzing with hardware.

AMAZON::B000087ZQC::Antec Sonata case AMAZON::B0002344O8::24" Rounded IDE cable

At work my dev environment consists of bash, vim, ant, jdk 1.3, vss, and a couple dozen bash aliases, bash scripts and python scripts. I spend most of the day in and out of vim sessions debugging various things.

Every 6 months or so I try to switch to Emacs full-time, but I need all the pieces to be there in order to switch and I don't have a lot of time at work to figure it out, practice and get used to a new dev environment. Thus for the last 3-4 years, I've been hanging onto vim, bash, ant, jdk 1.3, vss and tweaking my scripts to make the process as smooth as possible. There are parts that work really well and parts that suck. Debugging sucks.

I figured I'd check out Eclipse and Netbeans. I spent 30 minutes trying to figure out how to download Eclipse and set it up on Windows XP and got no where. I'm not really sure how so many people can use it--it's really difficult to get started. I spent an hour trying to get Netbeans to work with jdk 1.4.2 while compiling our stuff with jdk 1.3 and without stomping on the version of Java that runs applets in Internet Explorer. That sucked and could have been a lot easier.

After that, Netbeans seems to work pretty well. I'm running 4.0 beta 2. I bump into NullPointerExceptions regularly, but Netbeans seems to recover from them pretty well without me having to restart. It's decent. I fixed my first bug today with the "new dev environment". It's already faster to iterate between the steps of the analyze, fix, test cycle than it was before. I've also caught a few bugs I didn't know about which have been there for a long time all quiet and hidden away.

I still want to switch to Emacs, but it'll have to wait until I have more free time to make it work.

I gave Bill Mill CVS checkin permissions the other day. He's interested in working on the static rendering and the problems of storing metadata. The former (static rendering), I'm psyched to pass off to someone who will work on it and fix the various issues it has. At a bare minimum, I'm psyched to pass it off to someone who wants to think about it.

The latter (metadata) is something we need to figure out how to deal with and soonish. The pyblosxom-users and pyblosxom-devel mailing lists have had several people pop up with their own ideas about what constitutes metadata, where it should be stored, how it should be stored, and how to access it. But few, if any, of the proposals seem to be in-line with the PyBlosxom mission. Though maybe it's not clear what the mission is. That's a topic for another entry.

Bottom line is that I'm going to hold off on releasing pyblosxom 1.1 for a few days in case Bill wants to change things.

Bill Mill's weblog is here. He talks a bit about metadata in entries and del.icio.us-style keywords.

Also, SourceForge is finally getting around to updating their web-servers and are planning to install a version of Python greater than 1.5.2. When that happens, I'm going to re-do and move the PlanetPyBlosxom web-site. I'm hoping Wari will approve moving the PyBlosxom main site as well. If he does that, then I want to merge the two sites, fix our problems with documentation, and centralize everything under one big project web-site that's agnostic of the people involved. That's a bit project. It may be that I'll wait to do pyblosxom 1.1 release until after the "big move".

A while back, several people offered to help out but I severely lacked the resources to sort everything out to take that offer. I'm hoping to make development much easier for people who want to hop in, implement a feature they need, and hop back out again and also make room for growing PyBlosxom beyond its blosxom roots.

So that's the update. Any thoughts or comments, leave them below.

Things don't seem to click in the early morning. I know they should click because I remember them clicking yesterday. The early morning mental fog needs some time to roll away... to drift off into the corners of my mind so I can get something done today. It may come again tomorrow. Such is the way of things.

As my early morning mental fog is doing its early morning mental fog drifting, I usually get a cup of coffee or tea, sit bleary-eyed while reading through email, and then count the number of things in my todo list and divide by 10. I use that number to figure out early on whether I'm going to be measurably productive or whether it's just going to be one of those days where I spin my wheels a lot and don't really get anywhere.

I knew folks who had Konfabulator installed on their OSX-based machines and enjoyed it thoroughly. I'm not going to wax philosophical on how pretty it is and all that total hooey, but it is pretty useful and does give me the ability to build information-yielding widgets that Windows otherwise doesn't have.

Right now I'm using the weather widget and the todo item widget (both ship with Konfabulator) and I stick them on my other monitor (I'm running a dual-monitor setup at work). I can glance over and see my email client, the quick todo list, and the weather outside all on one screen.

It's been really useful so far. I'm tossing around adding stock tickers, but mostly that would just stress me out. I should add a calendar widget that queries my server (where I store all my calendar information). That would be super useful.

Anyhow, it's worth looking at if you need more information at your fingertips and can spare the screen real-estate.

I think I've removed over 100 spam comments from my blog in the last 48 hours. I'm a little tired of it, so I added a few obvious words to my word blacklist and then I went and modified the comments plugin to allow for "draft" status.

Then I wrote a small script that goes through the directory, finds all the comments in draft status, prints each comment to the screen and asks me what I want to do with it. That'll prevent comments from getting published without my manual approval.

It's funny to note that many/most of the comment spam are comments on my entries on comment spam.

Every once in a while, someone emails me about Stringbean and wonders why I'm not working on it much. Stringbean is more like an LPMud than a MOO and would allow for in-game coding of objects in Python. I've been giving a few reasons of why I'm not really actively working on it:

• It's not currently possible (without a lot of work) to build a restricted execution environment within the Python interpreter to protect the driver from the mudlib codebase if both are implemented in Python. That's not a wildly large issue except that it forces you to really trust in-game developers. The Zope folks have something like this in place, but I don't know if it would help me solve my problem or not. Mostly this requires a lot of research and work.

• It's difficult to terminate infinite loops and other long-running code which will cause mudlag. It's not uncommon for me to accidentally create an infinite loop. If you can't somehow halt execution, then this forces you to shut down the whole mud and restart it. When working on Varium, we created a reaper thread which would send a signal to the Python process causing the execution thread (which was the main thread of execution) to throw an exception and thus "terminate" execution. Even with this, it's not clear what state the driver would be in. This also requires a lot more research and work.

• I bumped into Twisted Reality (which is what this post is all about).

Twisted Reality is a MOO oriented mud so it's got a different focus than Stringbean does. However, Twisted Reality is also attempting to solve another big problem I have with muds using Aspects.

The problem is this: you build a bunch of objects the player can manipulate (things like torches, swords, hammers, nails, screwdrivers, etc) and in order to add another way for the players to manipulate and modify these objects, you have to code manipulation/modification-handling code for every single object. What if you wanted to allow players to burn an object? Well, for every object, you'd have to implement burn-handling code.

You could implement this using multiple inheritance. Each object inherits from a object-type class (armor, weapon, container, etc) as well as a material class (iron, wood, organic, copper, glass, etc). The material classes could handle effects like burning. But what if you had something like an axe with a wooden handle and an iron blade?

Anyhow, it'd be easier if the burn code could be centralized into one place--an aspect. The stuff in the Reality mailing list is interesting enough that even though I haven't looked into it further, it's caused me to want to wait to research it more before I go work on Stringbean again.

I just finished up my application for graduate school at Northeastern University!