Ray Platform: a message-passing-interface programming framework

The first pieces of Ray were put together in a git repository on 21 January 2010. Since that, Ray has undergo numerous major refactoring events.

The biggest changes to date are those of a few days ago. The source code of Ray is now divided in Ray Platform (around 13000 source lines of code including comments and blank lines) and Ray Application (around 29 000 source lines of code including comments and blank lines).

Ray Platform compiles independently of Ray Application -- it can be reused over and over again. I changed the license too. While Ray Application is still licensed under the GNU General Public License, version 3, Ray Platform is licensed under the GNU Lesser General Public License, version 3.

This means that Ray Platform can be incorporated in proprietary software (for free, if that matters). If changes are made to Ray Platform, however, these have to be shared.

How it works ?

The main class of the Ray Platform is ComputeCore. It represents a process mapped to a single processor core. An instance of this class has a message inbox, a message outbox, a virtual processor and a virtual communicator. The programmer can use the application programming interface to register callbacks for message tags, slave modes and master modes.

Message tag handlers

Any MPI message tag (type of message) has a default callback method to handle it that does nothing at all. Let's say the MPI tag is called MPI_TAG_GET_COFFEE. The corresponding callback is call_MPI_TAG_GET_COFFEE. The empty callbacks are generated in MessageTagHandler automatically. To overwrite one, a class that inherits from MessageTagHandler has to be defined with the appropriate new handler (with the same name). Then, the programmer needs to register an instance of this new class as being the handler of the MPI tag.

m_computeCore.setMessageTagObjectHandler(MPI_TAG_GET_COFFEE, &m_coffeeHandler);

Henceforth, when a message is received, Ray Platform will call m_coffeeHandler.call_MPI_TAG_GET_COFFEE(message).

Master and slave modes

In the Ray Platform, each ComputeCore has a current master mode and a current slave mode. The master mode of all ranks but the master is MASTER_RANK_DO_NOTHING. Just like for the message tags, the default handlers for slave modes and master modes can be overwritten with custom ones.



Making a github project readable as a web page

It is no secret, I love github (and git).

Today I updated my knowledge on javascript.

I started to wrote a game, the slim volleyball game to be exact (see reddit).

So I pushed the thing on github.
However, the files were not served as being part of a web page.

Fortunately, github implements a service called github pages which allows any github user to share a web page about something using the user's username.

This service also allows one to add a branch called 'gh-pages' (refs/heads/gh-pages to be exact I believe) to git repository to serve its content on the web. The content of the branch 'gh-pages' for projectX of userA is served as a web page at http://userA.github.com/projectX.

Initially, the only reference is usually 'master' (along with its remote twin).

seb@godzilla$ git branch -a
* master

To serve all the content of the branch 'refs/heads/master' on github pages, a symbolic reference called 'refs/heads/gh-pages' must be created.

seb@godzilla$ git symbolic-ref "refs/heads/gh-pages" "refs/heads/master"

Then you can list the branches.

seb@godzilla$ git branch -a
  gh-pages -> master
* master

The next thing you need to do is to push the references.

seb@godzilla$ git push --mirror

The gh-pages reference is now on the remote site too.

seb@godzilla$ git branch -a
  gh-pages -> master
* master

While the the project is available on github as usual, the same content is served on the web too !