Jacob Repp » meetup http://jrepp.com Game programming, music and life Fri, 16 Dec 2011 06:03:01 +0000 en hourly 1 http://wordpress.org/?v=3.0.4 Austin Ruby Meetup 1-17-2008 http://jrepp.com/2008/01/17/austin-ruby-meetup-1-17-2008/ http://jrepp.com/2008/01/17/austin-ruby-meetup-1-17-2008/#comments Thu, 17 Jan 2008 06:14:52 +0000 proj http://jrepp.com/2008/01/17/austin-ruby-meetup-1-17-2008/ Continue reading →]]> We had a good time at the meetup tonight. Steven and I busted out the laptops and shared some code and ideas. He had a nice rails app for learning Latin that supported a tagging architecture. I know next to nothing about rails so it was interesting to see the interactive console and scaffolding at work. We talked a bit about lisp compilation, writing, philosophy and open source vs. closed source. I demonstrated how you can specialize a method in SBCL using THE type declarations and the difference it makes in the generated machine code via DISASSEMBLE. As usual it was entertaining and enriching. If you’re in the Austin area and want to talk Ruby, Lisp, Python, C or whatever you should consider joining us.

]]> http://jrepp.com/2008/01/17/austin-ruby-meetup-1-17-2008/feed/ 0 Implementing a Finite State Machine with a Ruby Domain Specific Language http://jrepp.com/2007/08/14/implementing-a-finite-state-machine-with-a-ruby-domain-specific-language/ http://jrepp.com/2007/08/14/implementing-a-finite-state-machine-with-a-ruby-domain-specific-language/#comments Tue, 14 Aug 2007 09:12:21 +0000 proj http://jrepp.com/2007/08/14/implementing-a-finite-state-machine-with-a-ruby-domain-specific-language/ Continue reading →]]> DSL-FSM.. that kinda sounds like some wierd internet sub-culture. It stands for domain specific language – finite state machine. I proposed both topics as presentation material for the austin-ruby group that I meet with once a month. Steven Harms the organizer recommended both/either so I combined it into one piece of code as it actually works pretty well that way.

The DSL that I’m using is pretty small right now, which lends itself to easier understanding and explanation.

Ruby code tarball can be downloaded here.

A FSM is defined in a ruby script file without any class definition using the following rules:

  1. All attributes are specified in a method named ‘setup’. Setup takes an argument hash which may contain arguments that can be used to setup a FSM entity.
  2. All states are specified by defining top level methods with the name ‘while<statename>’. These methods are called in a tick update while that state is active.
  3. All transitions are initiated by saying start :statename
For example the creature FSM is has a method:
def whileidle
target_nearest

start :chasing if @target

end
All FSM entity templates can be loaded in the world using world.load(‘template-name’). The world is currently driven by a simple script named ‘simulate.rb’ which allows you to single step the world simulation and watch all the state machines make their choices. There are some debugging tools available. You can list all active entities and dump the world grid.

World#load uses the Object#instance_eval method to evaluate the contents of the FSM definition in terms of a FSM base instance. The FSM class defines some methods that can be called within the FSM definition to control state transitions and to access common methods.

Practically speak this is a very simple way to enable easy extension of a system. It provides an easier path to refactor the individual state machines and lowers the barrier to entry for writing state machine code. Additionally, it would be nice to include certain types of behavior from modules so that state machine authors could have easy access to some of the methods currently defined in creature FSM. This would include methods like target_nearest.  You could also mix in native C modules to get access to things like a path finding grid.

Ideas for playing with the code:

  1. Make creatures pick up the ‘ammo’ entities
  2. Make creatures compete for the ‘fark’ entities
  3. Add a new term to the FSM for state transitions. The method names should be named ‘whenchangingfrom<statename>, whenchangingto<statename>, whenchangingfrom<statename>to_<statename>’ and should be executed when those state change patterns are matched.
  4. Allow entities to die
Some Notes:

A great article about some of the different types of DSL creation and the mindset from one of the coders at 37signals:

http://weblog.jamisbuck.org/2006/4/20/writing-domain-specific-languages

Careful of using missing_method, it bit me in the arse a number of times:

http://redhanded.hobix.com/inspect/theBestOfMethod_missing.html

It’s really hard to track down bugs related to methodmissing, any code you write inside an object implementing this needs to be carefully checked. It can also lead to blowing your stack when an error in methodmissing recalls method_missing.. and on and on.

This little gem is nice to keep in your back pocket when trying to raise a descriptive exception:

http://blog.nicksieger.com/articles/2006/09/06/rubys-exception-hierarchy

]]> http://jrepp.com/2007/08/14/implementing-a-finite-state-machine-with-a-ruby-domain-specific-language/feed/ 8