The package is ready!!
Well, I had to settle for ignoring obstacles. And the turning and acceleration heuristics are pretty odd. Hopefully the rover will drift towards the origin.
https://trac.foognostic.net/browser/icfp08/trunk
Changeset 31 -- need to tag it.
Time to upload!
Time to break out the graph paper!
The client can send motion commands now. The server is spewing random telemetry entries rather than honoring the the rover commands. Also it has no map awareness -- just a shell to exercise the networking layers and build the skeleton code. At this point it's finally time to take a Cartesian plane ride! (sorry)
shoulda had a tweet
["3450", "aL", "-234.040", "811.100", "47.5", "8.450", "b", "-220.00", "750.00", "12.000", "m", "-240.000", "812.000", "90.0", "9.100"]
<Icfp_telemetry:0x1e050 @speed=8.45, @turn="L", @craters=[], @dir=47.5, @accel="a", @boulders=[#<Icfp_boulder:0x1dac4 @y_pos=750.0, @x_pos=-220.0, @opaque=true, @radius=12.0>], @ypos=811.1, @ts=3450, @aliens=[#<Icfp_alien:0x1d9d4 @velocity=9.1, @y_pos=812.0, @angle=90.0, @x_pos=-240.0, @opaque=false, @radius=0.4>], @xpos=-234.04, @home=nil>
finally, some client / server interchange
Finally! Basic client server interop: https://trac.foognostic.net/changeset/12
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 
