Hello, Sunday.

Well, I was hoping to have a network-enabled client and server by this point. Unfortunately concentration is in short, short supply around here this weekend. Take that with several large grains of salt -- everyone around here will tell you I get cranky when I obsess over things. Go figure. But I am still planning to deliver a solution.

So far I have client-side deserialization of all the packets implemented. The initialization and telemetry messages are the most complicated so those have rote testing. I think I'll write a server which reads from stdin and spits it over the socket. That should make testing pretty easy.

sweet!

having fun deserializing!!

<Icfp_boulder:0x40448 @x_pos="-220.00", @opaque=true, @radius="12.000", @y_pos="750.00">

<Icfp_alien:0x40394 @x_pos="-240.000", @angle="90.0", @opaque=false, @radius=0.4, @y_pos="812.000", @velocity="9.100">

Plans for today

Saturday is coming to a close. A perfect storm of big life events are whirling this weekend, especially today. So it's been really hard to focus today. But the skeleton code is starting to look somewhat lifelike, which is encouraging.

My goals for today are to have a client which can make the rover go right. That's it, just go right until the timer expires or Martians or craters take it out. 

code at last

Wow, my Ruby skills are much rustier than I expected. Grails would provide a better test experience (with some annoying startup time), but I still feel like Ruby was the best overall choice. I've put out some skeleton code for the board entities (aliens, craters, ...). I'm planning to have some abstraction around the network exchanges, some of that has been laid out too. This phase of the work is straightforward, leaning towards the tedious. But a nice clean job here will make the hard part, the navigation heuristics, much easier to write.

Picking a language

I was pretty tired last night so I crashed early with some progress made but many big open questions. For some reason it's really hard to pick a language. The final candidates are C++, Ruby, and Groovy. They all have 

• C++: this is where I cut my programmer teeth. The Boost libraries made C++ a final contender, no time to work with the default APIs or learn something like NSPR. Still, the skills are rusty. 
• Ruby: Every time I use Ruby I like it a lot. Skills not quite as strong as...
• Groovy: I've spent way too much time around javac lately. It would be easy to use Grails as a REPL and test harness. However, an expensive IDE is an unspoken requirement in the Grails community. I reject that entirely, even if it means submitting a half-baked groovy mode for emacs.

I would love to misuse Grails as REPL and test harness, but I am afraid of problems migrating the code into a standalone JAR file. Developing the controller code as a JAR from the start leaves some of the benefits on the table. Rejecting the expensive IDEs leaves me with printf debugging and mediocre indenting / syntax highlighting.

C++ has great support within Emacs and GDB. I'm pretty sure I've forgotten many important C++ coding rules and would hate to get bitten by them during development. Not the least of which is manual memory management... I admit to being spoiled here now.

Ruby isn't my strongest language, but the design of the language is very comfortable to me. Combine that with good IDE support and I think that makes it the best overall option.

That took entirely way too long. Not a good omen

ICFP contest 2008 kickoff

Okay, I've got the live cd image, the svn repo, the trac instance, and now the requirements. The goal is to navigate a Martian rover to the center of a rectangle. The immobile obstacles are the borders, boulders, and craters. Moving obstacles are Martians with 14 fingers worshipping a heartless pantheon of deities. The software to be written is the controller, which decides and guides the rover homeward.

My initial impressions:

1. Simple socket i/o required
2. It would be nice to have a UI for the board
3. Need to detect collisions
4. Need to deal with telemetry data
5. Need to remember that boulders will obscure other items
6. Five runs per trial, initialization sent once per trial.
7. Need to build the package
8. Need to pick a language

Big questions

1. Rotational velocity:  how to gauge this
2. How to represent prior moves? Simply an array?

ICFP 2008

The eleventh ICFP starts tomorrow. I'm going to try it and see how far I get. The results should be amusing.

In the meantime, trac and svn servers have been setup. Self-signed certs, so expect a warning. Ping me for an account!