Squashed a seg fault related to modifications of event handler list made from within an event handler.

Problem:
On receiving a message, we iterate through our list of registered event handlers to see which callbacks to fire. If a message matches a callback, then it fires that callback. However, if a callback for an event handler affects the list of registered event handlers (eg through addition of handler or removal), elements in list of event handler I was iterating over became invalid, causing a seg fault.

Solution:
All additions and removals of event handlers take effect *after* we've tried matching a message against all registered event handlers. All addition and removal changes to event handler list are queued, and applied at end of iterating over list. (Order: first apply all additions, then apply all removes.)
Note: this does not affect suspend and resume of event handlers. An event handler can be suspended or resumed from within a handler.

Reasoning:
We could have also immediately added and removed handlers, rather than queueing operations for end. However, it seemed that reasoning about what a program would actually do became very difficult. For instance, users would have to know what order handlers executed in to determine what the results of a program would actually be.

-Behram

Done today:
When register handler, returns an object. This object supports suspend, resume, and printContents. (Suspend will prevent the handler from firing, resume allows a suspended handler to resume firing, and printContents prints the pattern data that causes a callback to fire.)

--Still need to print the callback in printContents.
--May want to make it so that all handlers are accessible through some type of system array. (If you lose track of the object you assigned to the handler, currently, you're out of luck.)
--Probably put off until users demand: make it so that can reset the callback from the handler object.

Bugs fixed:
--Can match against values again. (Needed to create persistent objects for values in JSPattern.hpp.)

Decisions made:
--Will not support multiple senders to match in event handlers. Reason: users can always do dispatch within a function, and membership that would match an event handler is likely to be dynamic. Downside: could lead to some bad coding practices. For instance, someone might iterate over an array, creating separate handlers for each potential sender in the array. These handlers would do the same things: would be difficult to modify, inspect, and play with.

--Holding off on a "default" handler. Default handler is invoked if no other handler matches. For now, not adding it because no concrete use case. Additionally, makes difficult to reason about what happens if users do some additional checks in their handlers that aren't relevant.

--I'm leaning heavily towards dispatching all handlers with matching patterns. Ewen mentioned doing something along the lines of strongest match, but that seems like a can of worms: how do you measure strongest? If you say that it's the most fields, then you can still have ties.

Current status:
--Broadcast works. (__broadcast(obj))
--Can send specific messages through system.addressable array.
--Objects serialized. (Can pipe around code with this + messaging)
--Pattern matching (minus prototype) works.

registering callback for multiple senders and a given pattern

today we argued on whether is it useful to have a list of senders as part of system.registerHandler().
It is not clear how useful this feature is to have at level of the language. Seems like a librarish type of feature. For example, exposing  system.addressable is enough and then system.broadcast just becomes a library feature. Similarly, how frequently user would actually want to register a set of senders for a particular pattern. Also, this list has to be static list => how frequently do users know their senders beforehand at the time of registering the callback.

In the bulletin board, user really didn't know the senders beforehand ( until they registered) and so callback was registered when the users were registered i.e. one at a time. Additionally, having an array of patterns might not be a good idea when we anyways plan to have "regex" for patterns.

It is certainly a useful feature and we should, as we write more scripts, evaluate the usefulness of this feature. We might end up incorporating this in emerson.

Doxygen documenting

Add the support for the Emerson API using doxygen or any other popular document generating tool.
Also, integrated the documenting process with the build.

Objects and Regular Expressions

Currently pattern matching does not use "regex" for the fields. Field name can be a regex. Field values which are string can be a regex.  Also, the value of a field can be an object and we need to do some pattern matching recursively. Need to add the support for objects as the field values.

Resume and Suspend

have two new functionalities:

• suspend: This is like temporarily disabling callbacks for a script. This is good because if an entity goes bizarre after executing some callback, it should be easy to disable a callback. 
• resume: re-enable a callback which has been suspended. The callback must be register for resume.

suspend and resume can happen for event callbacks that have been registered.

We currently have a "system.reboot" which clear the complete state of the script. This is like getting a new scratchpad..

some more work

There are multiple events in the system: Communication, Timers, Proximity and Motion. Can we unify them to a generic events; after which all events would be handled in a uniform way. However, the emerson syntax may be different for them.

         Eg. for timeout events we have:

         system.timeout(30, callback)

         OR we could have

        timer_id = timerEvent(30);
        register_handler(timer_id,  callback);

need to think how we can get all the events to be treated the same way in the runtime

Scoping questions:
--->There's an issue with whether variables are going to be looked-up/written to local objects or global. For instance:

class ()
{
x = 3;
function mFunc()
{
x=2; //local x, or class's x
}
};

Another way of doing things is to have self.x/this.x be for global. Javascript gives var for local. Do we just want to force using var?