Burst & Record

It took me much longer than I expected to implement the record feature in Weapon M's terminal. Things have been blowing up at work and I have very little code juice to spare. In contrast to how I've felt in the past, I don't merely need a break from work projects; I need a break from coding entirely. I'm glad the holidays are coming up. When I get back to it, I plan to tie up a few loose ends with regard to opening and saving databases. Then I'll begin reviewing all the data lexer rules from version 1.

Bursting with Awesomeness

I've been working on the burst feature for Weapon M's terminal. I actually had it working and then decided I wanted to add more features, so I mocked up a new version:

The burst panel is a small panel that pops up at the bottom of the terminal window when you press Ctrl-B. The combo box will allow you to input a new burst or select from a configurable number of bursts that were previously sent. You'll be able to send the burst as many times as you like, either by pressing enter or clicking the "Send" button repeatedly, or by setting the number of repeats in the spinner. The burst panel will be hidden when you press escape.

I'm combining the burst feature with a SWATH-like "quick macro" recording feature. If you press Ctrl-R while the terminal has focus, it will display the burst panel with a blinking "record" icon but keep the focus on the terminal. Any keystrokes sent to the game will also be appended to the combo box. To stop recording, press Ctrl-R again or focus one of the widgets in the burst panel using the mouse. The burst panel will then behave as though it had been shown with Ctrl-B.

JTX Selection Control

I've been working on the long-awaited selection control for JTX. I made some non-backward-compatible API changes to support it, so I branched version 1.x and bumped the trunk to 2.0-SNAPSHOT. And since I'm breaking the API anyway, I took the opportunity to make a bunch of other incompatible changes, including removing the synchronization from Display and ScrollbackBuffer and changing all the package names to reflect my domain name. I may also change the parameter order of some of the methods in the Buffer interface.

This is what it looks like in action:

I still need to add methods to copy the selection out of the control. I also plan to provide a means of converting the selection into various useful formats, such as ASCII bytes or the Unicode characters that correspond to the glyphs of IBM code page 437.

Dark Matter Update

The development of Dark Matter is proceeding swiftly. It functions as a terminal now. I'm copying classes in from Weapon M and reviewing them as I go. I've already fixed a few stupid bugs in the old code. There's currently a bug in JTX where it doesn't scroll to the bottom when the scroll pane's client first becomes larger than the viewport. This happened occasionally in Weapon M, but it seems to happen all the time in Dark Matter. I expect it'll be an easy fix.

The maintainer of DockingFrames does not want to maintain a Maven repo, so I forked it and deployed docking-frames-core, docking-frames-common, and docking-frames-ext-glass in my own repo. I also deployed Steffen Kux's glasslib. Dark Matter can now be built with Maven, but I haven't written the assembly module yet, so the resulting jars cannot be run without a bunch of dependencies on the classpath. Soon!

Dark Matter

I'm finally getting around to working on the new version of Weapon M that I mentioned back in July. It doesn't do much yet, but I'm really excited about it. It's going to solve a lot of the problems that prevented the original version from achieving its full potential. And it's going to look super sweet, which is critically important. The early code is up on GitHub.

The Database Revisited

I've been working on Weapon M again. It feels great to work on my own code, even if it's only for a few hours a week. The difference between programming as a hobby and programming as a job is like the difference between painting a canvas and painting a house.

I've made two decisions regarding the database. First, as much as I'd like an excuse to learn how to use a graph database, Weapon M isn't it. I can't see any benefit to it when the entire graph of POJOs is already accessible to scripts, and serialization works just fine for persistence. And second, I've decided to simplify the synchronization to a single lock shared by the entire database.

Crazy, you say? A huge performance bottleneck? That's what I initially assumed. But the simplicity of a single lock was so alluring that I had to write a simulation to test my assumption. It consisted of two small programs, each of which starts and then joins with two threads. One thread writes random values to the fields of mutable objects in an array, while the other reads them. In one program, the threads contend for a single lock. In the other, they synchronize on the individual object they are reading or writing.

Each program performed one million reads and one million writes on one hundred objects. The program in which the threads were contending for a single lock consistently runs in 140-170 ms; the other runs in 90-100 ms. That's a pretty significant difference, percentage-wise. But remember, we're talking about two million field accesses in a fraction of a second. Things do not happen that fast in Trade Wars! And this is on a G555 Celeron, a fairly low-end processor by today's standards. When the programs are modified to perform only ten thousand reads and writes, the performance difference is completely lost in the overhead of setting up the threads. And increasing the number of objects being manipulated to decrease the lock contention and give the program using individual locks more of an advantage does not significantly affect the results.

My conclusion is that there would be no significant performance penalty to using a single lock. The benefit would be significantly simpler code, eliminating the possibility of any lock-order bugs that could lead to deadlock.

Swing Docking Frameworks

I've been evaluating Swing docking frameworks in preparation for a major overhaul of Weapon M's UI. I wrote small demo programs using InfoNode Docking Windows, VLDocking, and Docking Frames to get a feel for their quality and the difficulties of working with them. All three exhibited problems managing keyboard focus on dockable components. InfoNode was a strong contender, and it's probably the quickest and simplest way to write a nice docking UI. But I'm declaring Docking Frames the winner on the basis of the project still being actively developed (or at least, as the developer prefers to say, actively maintained) and the fact that the Eclipse theme with the Glass Extension looks incredibly sleek and professional.

I'm actually thinking about a lot more than a UI overhaul. I've started planning a complete rewrite to incorporate lessons learned from 1.x. Version 2.0 will be a single, modular Maven project including the scripts and zip assembly. It will have a unified parser-to-UI event system, as suggested by a user. And it will address weaknesses like issue #22.

The biggest decision I have yet to make is whether I should replace the crude serialized object graph with a real embedded database. If I do, it'll be an OODBMS or a NOSQL graph database, but I've only barely started comparing the available options.