Fibra grows events.

Fibra has grown an event handling plugin.

  1 import fibra
  2 
  3 
  4 def task_a():
  5     for i in xrange(10):
  6         yield fibra.Send('AN_EVENT')
  7 
  8 def task_b():
  9     while True:
 10         msg = yield fibra.Recv('AN_EVENT')
 11         print 'Received:', msg
 12 
 13 def test():
 14     s = fibra.schedule()
 15     s.install(task_a())
 16     s.install(task_b())
 17     s.run()
 18 
 19 if __name__ == "__main__":
 20     test()

Now I need to reinstate the networking layer... and think about adding multi-core features via the new (in 2.6) multiprocessing module. It would be nice to have events magically transferred across process boundaries. FibraNet used to do this, but I haven't found a clean way of adding this to fibra, yet.

Due to popular demand...

...another gamejam has been scheduled for November 14-30. Short notice I know. Apologies.

I had hoped to deploy a new version of the gamejam.org interface, but I simply don't have the time. Next year, perhaps.

The previous gamejam was quite successful, so if you feel inclined, feel free to join in.

The Attraction of Dynamic Languages.

Today, a friend asked me, "Why are you attracted to dynamic languages?".

I didn't have a ready answer. After thinking about it for a while, I can list some good reasons why I prefer to work in Python, which is a dynamic language. Lately I have been writing a lot of code in C and C# (directly re-implementing Python algorithms), so I think I am in a good place to pass comment.

1. Python code is ~10% the size of my equivalent C# code. This means less typing, faster prototypes and less room for bugs.


2. Dynamic languages really do promote loose coupling. There is no dependence on types. This helps the programmer write re-usable code, and actually re-use it, rather than hide it away in some dusty, forgotten SVN repository...


3. Python works rather well with C. It's a piece of cake to convert a Python function into C code, then call them using ctypes. This fits perfectly with an incremental development method, where a prototype can slowly be converted into C code as needed.


4. Late binding lets you do some really clever stuff, and makes things like state machines very compact and easy to code and understand.

I've also found a few things in mono.net which I wish I had in Python.

1. A standard, OS independent socket implementation.


2. ...hmm not much else.

Have I missed anything?

Burning out...

Too many projects. Too many people asking for things.

No time for the things I really want to do.

How do _you_ prevent burn out?