This past weekend I released a new open source project called Easy Lua. It’s a wrapper around the Lua port that is included in Adobe’s open source CrossBridge project. It lets you easily integrate Lua scripts into any ActionScript project (Flash, AIR, etc) with a minimum of headache and zero knowledge of Lua’s C API.
CrossBridge is an amazing piece of technology that unfortunately receives little press. In summary, it combines GCC with FreeBSD’s libc and allows you to compile C/C++ code to ABC bytecode. Since ABC is the native bytecode for Adobe Flash and AIR, you end up with a version of Lua that can fully integrate with all of Adobe’s runtimes (mobile, desktop, and web).
The main use case for Easy Lua is to add Lua scripts to ActionScript based games. I plan on using it to implement card game engines in Lua so that the engine can be used both on the client (single-player mode) and on the server (mutli-player mode). This will mean less development time, more code reuse, and hopefully fewer bugs.
As mentioned in my previous post, Totem is a new Ruby project generator that I’ve put together. One major missing feature was the ability to easily create services (also known as background processes or daemons). To solve this problem, I have created an add-on gem called Raad – Totem. It is a fork of the original Raad gem with a number of customizations to integrate it with a Totem project. Much thanks go to the original Raad authors since they were able to make it work for both Ruby and JRjuby.
Totem is my new Ruby gem for creating Ruby projects without having to depend on Rails. Some of the features it provides are:
- Interactive console
- Standard folder structure (very Rails like)
- Environments (development, production, etc)
- Easy database access (via an add-on)
Totem and Totem – Activerecord seek to bring these and many other features to your non-Rails application. Give it a try and feel free to contact me with your feedback.
I’ve added a few missing features to Tribe– Timers and Futures.
Timers provide a way to tell an actor to do something in the future. Tribe supports both one-shot and periodic timers so I believe all the major usage patterns are covered. Adding this feature was fairly easy since all of the low level details are hidden in my Workers gem.
Futures make it easy for an actor to ask another actor to perform an operation and return the result. Previously you would have to use custom events and a lot of boilerplate code to accomplish this. Both synchronous (blocking) and asynchronous (non-blocking) futures are supported. More information on both types can be found in the readme file.
Recently I added a number of features to my Workers gem:
The Task and TaskGroup classes make it even easier to parallelize expensive computations (and blocking IO operations) using background threads. They build on top of worker pools and standardize on various features such as success/failure handling, delayed execution, and arguments.
Parallel Map is syntactic sugar built on top of tasks and task groups. It works very similar to Ruby’s standard Array#map method except each element is mapped in parallel.
Pools are now dynamically resizable. The long term vision for this feature is to experiment with auto-resizing algorithms that adapt to an applications load. In the short term it is mostly useful for quickly changing the size of the default pool (currently set to 20 workers) without having to create a new one.
Recently I put together two new Ruby gems called Tribe EM and Tribe EM AMF Socket. Both gems build on top of my Tribe gem.
Tribe EM bridges the gap between Tribe and EventMachine. Currently it provides basic TCP server functionality for Tribe actors. My intent is to use this as a base for implementing higher-level protocols such as HTTP.
Tribe EM AMF Socket is a wrapper around my existing AMF Socket – Ruby gem. Currently it only supports messages and not requests (RPC). I believe this to be a reasonable limitation for now since AMF Socket messages fit in very well with Tribe’s asynchronous messaging system.
One key difference between the two gems is what I refer to as native vs wrapper implementations:
Native: The Tribe::EM::Connection class is considered native since it pushes the higher level protocol implementation onto the actor threads. This results in greater scalability since actors take advantage of multi-core systems (especially on JRuby).
Wrapper: The Tribe::EM::AmfSocket::Connection class is considered a wrapper since it wraps the AMF Socket gem for use with Tribe. This means that a lot of work (serialization, deserialization, framing, keep alives, etc) are all performed on the EventMachine thread. The result is lower performance than a native implementation, but less coding since I can reuse the existing Ruby implementation of AMF Socket.
Both gem are designed to be easily customized. Feel free to contact me with your custom protocol implementations so that I can add them to the Tribe EM homepage.
Recently I’ve created two new Ruby gems known as Workers and Tribe.
The Workers gem turns low-level operating system threads into simple to use event-driven workers and worker pools. This allows you to focus on message passing instead of complex thread management. As an added bonus, it includes a timer system that can tell your workers to execute work in the future.
The Tribe gem builds on top of Workers in order to implement the actor model. It specifically focuses on event-driven actors such that each thread manages one or more actors. This way the system can support many more actors than is possible with implementations that force a 1:1 thread to actor relationship. A simple benchmark demonstrating one million actors using 20 threads can be found on the performance wiki page.
Both gems have been tested with MRI Ruby 1.9.3 and JRuby 1.7. Due to MRI’s thread limitations, it is highly recommended that you use JRuby if you are concerned about multi-core CPU performance.