Table Driven Madness

I've contemplated further work on NedOS, but the current barrier is pretty high. In order to enable interrupts (new style - ACPIA, not legacy PIC) I need to parse the AML tables. Retrieving the code isn't hard, but parsing it is a nightmare.

I have the source code of the Intel reference parser. It reminds me of some code from an earlier project - the table driven state machine.

Instead of a human readable handler (say for a FPS):
void onEvent(type)
{
switch(type)
{
case KEY_A: move_left();
case KEY_D: move_right();
case KEY_SPACE: fire();
}
}

you have this:
while( curState != END)
{
get_input(&input);
output = table[curState].out;
curState = table[curState][input].nextState;
}

On our project this made at least some sense. The hardware under development had the same tables, which allows you to fix bugs by patching the table ROM.

For pure software, I don't see the point. Now, instead of being able to read through some code and figure out what is going on, I get to state at tables like this:
/* Index Name Parser Args Interpreter Args ObjectType Class Type Flags */

/* 00 */ ACPI_OP ("Zero", ARGP_ZERO_OP, ARGI_ZERO_OP, ACPI_TYPE_INTEGER, AML_CLASS_ARGUMENT, AML_TYPE_CONSTANT, AML_CONSTANT),
/* 01 */ ACPI_OP ("One", ARGP_ONE_OP, ARGI_ONE_OP, ACPI_TYPE_INTEGER, AML_CLASS_ARGUMENT, AML_TYPE_CONSTANT, AML_CONSTANT),
/* 02 */ ACPI_OP ("Alias", ARGP_ALIAS_OP, ARGI_ALIAS_OP, ACPI_TYPE_LOCAL_ALIAS, AML_CLASS_NAMED_OBJECT, AML_TYPE_NAMED_SIMPLE, AML_HAS_ARGS | AML_NSOBJECT | AML_NSOPCODE | AML_NSNODE | AML_NAMED),
/* 03 */ ACPI_OP ("Name", ARGP_NAME_OP, ARGI_NAME_OP, ACPI_TYPE_ANY, AML_CLASS_NAMED_OBJECT, AML_TYPE_NAMED_COMPLEX, AML_HAS_ARGS | AML_NSOBJECT | AML_NSOPCODE | AML_NSNODE | AML_NAMED),
/* 04 */ ACPI_OP ("ByteConst", ARGP_BYTE_OP, ARGI_BYTE_OP, ACPI_TYPE_INTEGER, AML_CLASS_ARGUMENT, AML_TYPE_LITERAL, AML_CONSTANT),
/* 05 */ ACPI_OP ("WordConst", ARGP_WORD_OP, ARGI_WORD_OP, ACPI_TYPE_INTEGER, AML_CLASS_ARGUMENT, AML_TYPE_LITERAL, AML_CONSTANT),
/* 06 */ ACPI_OP ("DwordConst", ARGP_DWORD_OP, ARGI_DWORD_OP, ACPI_TYPE_INTEGER, AML_CLASS_ARGUMENT, AML_TYPE_LITERAL, AML_CONSTANT),
/* 07 */ ACPI_OP ("String", ARGP_STRING_OP, ARGI_STRING_OP, ACPI_TYPE_STRING, AML_CLASS_ARGUMENT, AML_TYPE_LITERAL, AML_CONSTANT),
/* 08 */ ACPI_OP ("Scope", ARGP_SCOPE_OP, ARGI_SCOPE_OP, ACPI_TYPE_LOCAL_SCOPE, AML_CLASS_NAMED_OBJECT, AML_TYPE_NAMED_NO_OBJ, AML_HAS_ARGS | AML_NSOBJECT | AML_NSOPCODE | AML_NSNODE | AML_NAMED),

Oh yea, that makes total sense. I see exactly what's happening here...

Stuff I've read lately

"G is for Gumshoe" (Sue Grafton)(audio) - I was surprised by this one. It was kind of hard to believe someone would care enough about Kinsey to put a hit on her. Harder to believe someone would take the offer for $1250 (actually $5000 for four people, including a judge and a DA). The story is somewhat confusing when the gunman ("G is for Gunman"?) shows up at the home of someone Kinsey is investigating. Who turns out to be a mass murderer, who is killed by the gunman. At least Kinsey managed not to kill anyone...

Stuff I've read lately

"M is for Malice" (Sue Grafton)(audio) - I was surprised, this story actually had a character with a credible Christian testimony. I suddenly realized, "this guy is so dead". I was right. Again, it was impossible to determine who the murderer was. Not for lack of suspects:

1. The older brother - work-aholic, possibly upset over money, bitter about past wrongs
2. The younger brother - going through hero worship disappointment
3. The youngest brother - always in need of more money
4. The cook - feelings of disappointment to the family honor
5. The nurse - who is so nondescript, even the other characters forget she's around most of the time

For a while, I figured it was #1. #2 gets arrested, and evidence points at #3. #4 really seemed to have some potential. So, of course, it was #5.

The worst part was there was a family which had been wronged in the past (mentioned briefly in the beginning, with no detail until near the end). But they were all supposed to be dead. Of course, one member had faked her own death, and set herself up as nurse so she could murder them. Of course.

Stuff I've read lately

The Great Courses: Famous Romans (Rufus Fears)(audio) - This was not what I was expecting at all. It was more like a performance than a lecture. People were clapping at the end of each session...

Stuff I've read lately

"F is for Fugitive" (Sue Grafton)(audio) - I'm reminded of the old TV series "Murder She Wrote" (or, as I liked to call it "Murdered She Was"). Every week Jessica Fletcher (who was also the mother of the "Manchurian Candidate", aka John McCain) visits a relative (she had a lot!). And every week, that relative gets framed for murder, and Jessica needs to find the real killer.

I began to realize the incredible improbability of such events. It was far more likely that Jessica was the murderer. She was also skilled at framing people, as she would frame her relative (sloppily) while actually framing a third party so well (and tormenting them the whole episode - Columbo style) that they would confess!

This time, Kinsey shows up in a small town to investigate a murder from 17 years ago. By the time she is done: the accused murderer's friend and mother are dead, and the original murderee's mother is dead!

Not safe to be around Kinsey!

Stuff I've been reading

"E is for Evidence" (Sue Grafton)(audio) - Should be "E is for Explosions". Kinsey gets blown up (reeal goood!) twice. I don't think she's blown up at all in the other books...

I'm not sure what category these books fall into. They can't be "Whodunit". It's nearly impossible to figure out before the end. Half the time, I have to replay the ending just to figure out why the killer did what they did.

Stuff I've been reading

"Zoe's Tale" (John Scalzi) - I really enjoy the "Old Man's War" universe, and Scalzi's style. That said, I am rather disappointed with this one.

Zoe's Tale is basically a retelling of "Lost Colony" from the point of view of Zoe. In the Acknowledgments, Scalzi tells how he thought this book would be easy - but it turned out very hard. Given his rather low bandwidth (one per year, which is typical for authors), I'd much rather see a new story.

I don't like to reread books. This one was different enough, and it has been long enough since I read LC, that I wasn't bothered. It was somewhat engaging; although it is more characterization, where the other OMW books focus more on events.

Since You've Been Gone

I couldn't hurt anymore
if you dropped a two-ton bowling ball on my toes

Since You've Been Gone
(O Since You've Been Gone)

You know I've been in a butt-load of pain
Since You've Been Gone


I feel almost as bad as I did
When you were still here!

Stuff I've been reading

"Claws That Catch" (John Ringo) - It's been a while since I've read any SF. Ringo comes through again!

The main thing I like about Ringo is brevity. This book is 343 pages long, compared to 600-800 for somebody like Stephenson.

Ringo captures the "hurry up and wait" and "long stretches of boredom, followed by moments of terror" of military life. There is no encounter with the enemy until page 278 - yet, he makes the "boring" parts interesting and funny (along with providing good characterization).

The closing action is as good as any you will find (with boarding actions, giant space battles, and fighters).

I hope Ringo keeps writing lots of books!

NewStars Status

Whew, been a while... I have been putting off work on NewStars. I was afraid of "GUI load/unload", that is, the shuffling of cargo using the GUI. These orders have a separate order type from "Waypoint 0" (both happen before move). I was worried I would need to evaluate these orders in order to show the current levels on planets and in ships. Then, I would need to hide the orders in the order box, yet update the orders when the GUI instructs.

I figured out a way around all that. I left the GUI orders in place (visible and not evaluated) for loading/unloading to a planet. For ship-to-ship, I edit the XML (the reconciler handles edits in the XML).

The basic GUI is now ready:

Here we can see a transfer between the medium freighter and colony ship for player 1. The orders are executed when the window closes (I should add Cancel and Ok buttons...)

With that, everything needed to play is in the GUI!

Stuff I've been reading

"S is for Silence" (Sue Grafton)(audio) - I should gather statistics on how many people are killed in California. It seems like all of them are near (or killed directly by) Kinsey Millhone...

Stuff I've been reading

"N is for Noose" (Sue Grafton)(audio) -Meh.

Robot Builder

(continuing my review of Facebook games)

I previously mentioned a group that made several good games. The best of these is Robot Builder.

Robot Builder originally suffered from the same Add Me effect that most games have. Then some sort of bug caused them to remove it (this was before I started). They never did re-enable it, which turned out to be a great decision.

Game play is pretty simple. You have several resources to manage: energy, money, and robot tokens (RT, this is how they raise money, you can buy RT - although you can also find them in the game).

Energy is refilled at 10 per 15 minutes (as opposed to the typical 1/4 or 1/5). This is somewhat irritating early in the game, when you only have 10 or 11 max.

Your goal is to build robots. There are many different areas to salvage through (which take energy and money, sometimes RT). You can also do different "fights" in the arena - but these are basically different areas which can only be explored once per hour (or four hours, I forget).

You mainly raise money by selling parts, energy refills automatically, and you find RT. Different robots allow access to different arena fights, new areas, or give you additional energy storage.

Not a lot to see.

The hidden gem in this game is the market system.

The market allows players to trade items for RT. You can sell your rare parts (any parts really) for RT, and buy the parts you need. Or buy parts to sell for cash (giving RT a value in cash).

Being a market, there are tidal effects (as players sign off for the night, or sign on in the morning). This creates timing opportunities. You can buy parts when there are many players online as an investment, then sell them off when the market is short. You can also try to corner the market (by buying all the parts others supply, and holding out for higher prices).

This gives the game a lot of playability - even when there is no new content. It does require a large number of players to support the market. Sadly, total abandonment by the developers has pretty much killed this game.

Stuff I've read lately

R is for Ricochet (Sue Grafton)(audio) - It's interesting to bounce back and forth in the series (as library availability allows). The last book was from the 80's (or early 90's) and was 6 CD's. This book is from 2004 and is 10. There is not >50% more story...

I was especially disappointed that there was no ricochet. It is funny to hear a story about old time computers (carried in rolling luggage) and handfuls of floppy disks.

Frontierville

(continuing my review of Facebook games)
A quick word of warning about Zynga games (Mafia Wars, Farmville, Frontierville, among others). They are pretty public about how evil they are. They will sell you email to spammers, and do anything to spread to your friends and install toolbars on your browser. If you play their games (and I can't recommend any of them), make sure to use NoScript, Adblock, etc. and don't give them your email, make sure you block them from your wall and friends, etc...

So, continuing on the massive failure that is Farmville, there is now Frontierville.

The game mechanics (and engine) are basically the same - you have a set of land, on which you place buildings, crops, trees, and animals.

There are a number of changes, most of them bad: energy, wilderness, varmints.

Energy
In Farmville, you could plant your whole board in a 4 hour crop, come back in 4 hours and harvest it all (assuming you had the money). In Frontierville, every action takes 1 energy (like the energy in Mafia Wars). Of course, in Mafia Wars I have 1900 energy (at 1 energy per 5 minutes, that is 8 days). In Frontierville, I have 15 energy.

This does introduce some interesting strategy changes.

Now, you must pipeline out some crops in order to maximize experience. You can't just look at xp/hr, you must include energy as well (since all actions are 1 energy, this amounts to xp/crop). So, 3 day crops are the best, but you can't just fill the board with them. You have to stage them out, say 1 hour apart, 9 at a time (not 12, more later). This creates some interesting effects, when you start with a blank board, and want to scale up to a big harvest in 2 or 3 days (say over a long weekend). You lay down 9 of the 3 day jobs, and 9 one hour jobs (for when you come back). Then, in an hour, harvest and lay down 9 more of the 3-days. Rinse and repeat.

Wilderness
The wilderness is a huge pain. Your board is not open like in Farmville. It starts covered with all sorts of junk, which you have to expend energy to clear. Worse, the stuff grows back.

Varmints
This is probably the worst feature of all (especially when compounded with the other two). Every action has a chance to spawn a varmint (different ones for different actions). The varmint will block the 8 adjacent squares, forcing you to deal with it or pay 2 energy for actions. It takes 3 or 4 energy to remove a varmint (hence the 9 crops for a 12 energy period). If you luck out with no varmints, you need the energy for maintaining the wilderness anyway.

The game's isometric view is especially painful here. One time, I was clearing some trees, and a bear appeared. It was hidden behind a big tree, so I had to pay 2 energy times 12 to clear that tree!

Co-op Play
There is one nice new feature. In Farmville, you could visit your friends' farms. There you could get some extra xp and money by "helping out" (which actually did not help them at all). In Frontierville, you can actually help. This makes things a little better, but is not usually reliable enough to impact planning. You usually have more things than you have energy for, and friends can help there.

The game has just started, so it might get better - but probably not.

Farmville

(continuing my review of Facebook games)

Farmville is a really bad game. Shockingly bad - especially considering how many people play it (Wikipedia claims 80 million installs).

The game mechanics are very simple, you have a set of land (which gets bigger as you progress) which you can fill with crops, trees, animals, and buildings. Buildings serve no point, except to give you experience points (and look pretty).

There is an interesting trade-off between crops and trees/animals.

Every unit of production has some cost, and produces some experience points and money. Trees and animals produce repeatedly, while crops are one-shot. Also, crops will expire (wither) if they are not gathered after reaching term - while trees and animals will keep indefinitely.

The optimal strategy is to maximize your return in money and experience (money can buy experience) for the land you have, and the time you have. If you can dedicate lots of time, you can make a lot of money and experience very quickly.

Higher levels give access to new crops, etc. but this is of limited effect. You have your spreadsheet of $/hr and xp/hr, grouped into time groups (4 hours, 8 hours, 1 day, etc.). Based on your schedule, you put down some crops. If you aren't sure when you will be back, you can invest more in trees or animals.

At some point they added vehicles, which reduces the tedium of plow/plant/harvest some (a vehicle can do 4 at a time). Not really worth the time, though.

I'm a Wiener

(continuing my review of Facebook games)
I got style, I got grace.

Perhaps the saddest part of Facebook games is the lack of winning.

For some reason, game designers think that if they don't have an ending, and don't declare a winner, people will just play forever.

Of course, this requires a steady rollout of new content. So really, you're just playing new games with a steady increase in gear - which leads to massive inflation (old gear becomes useless).

Usually, the developers can't keep up with the rate of consumption, and the game dies anyway.

So, ironically, the very attempt at creating a unending game ends the game (there's a sermon in there).

Stuff I've read lately

"D is for Deadbeat" (Sue Grafton)(audio) - This book actually covers some of Grafton's view of Christianity, and its not positive. Still, the book was moving in a way that these usually aren't.

Stuff I've read lately

"C is for Corpse" (Sue Grafton)(audio) - It was ok.

git rebase /home/you us

(That's "all your base are belong to us" in git-speak)
I think I am starting to get the hang of git.

The key is not to think of "versions" of the codebase, but rather, in terms of "patches". Git is not "version control" it is "patch management".

The rebase command is an excellent example of this, and it is really unusual and powerful (which can make it dangerous).

The best thing about it, is that it allows you to avoid the "shoulda syndrome".

For example, imagine you are working on a new feature. You spot a bug, and fix it on the spot.

In cvs or subversion, you have violated the "shoulda" policy dictated by these tools. You "shoulda" put your current changes somewhere else (or used a new area, I have about 4 local copies of my svn work project).

Now, in order to commit just the fix, you are going to have a lot of pain and suffering to split things out, test it, and commit it, then merge back.

But in git, there is no "shoulda". You can fix that bug, and carry on with life.

How so?

First, you need to get all your changes into patches. Use "add -i" (interactive) to get everything in (add interactive allows you to commit individual lines from a file, if necessary). Then you can use branches to test just the patches you want to commit.

The real power comes from rebase.

Rebasing is confusing (and potentially dangerous), because it allows you to edit the history of the repo.

It is also two different commands in one.

The first command is plain rebase (git rebase <relativeHead>). This is used in place of "git pull" to update a working branch (keeping it relative to that branch, rather than merging).

The second command is editing history (git rebase -i <relativeHead>). This allows you to shuffle the order of patches, and merge patches.

So if the patches to your working area are:
trunk
Start of new feature
Additional feature
More stuff
Bug fix

You can shuffle the bug fix up to right after the branch from the trunk. You can then push that patch into the trunk. Your working area is clean, and you don't have to bother the trunk with all your intermediate commits.