system.presences

Concretizing our concept of presences and separating the entities from presences, we have a new reference to system.presences in the Emerson.  At present, we have two addressable arrays:  system.presences and system.addressable .  Presences are the self address of the hosted entity each in different space. IT is just a logical connection. Currently, we just store the spaceID of the space in the presence javascript object which should be sufficient for most purposes.  Addressables lets the script to refer other presences of other entities. However, addressables will contain presences too.

Following this, work needs to be done to unify addressables and presences. The idea is that a presence can do few things synchronously too while addressables will always require the asynchronous messaging. A bit more thought has to go into designing this. Currently addressable does not store the space information of the entity. And this has to be incorporated too.

Next thing would be to add functionalities like system.presences[0].setMesh  and other functionalities similar to this. All these are inbuilt into system currently and assumes the default connection to the space.These have to be made space specific.

system.create_entity

Emerson finally has the ability to create scripted entities from an executing script. This is achieved by following


           system.create_entity(Vector3d pos&)


The (presence of )new entity will be at the position specified by pos and with other default location properties. Entity creation is an asynchronous operation and will not block the running script. The script for the new entity is initialized only after the new entity is connected to space.


There are few things that need to be solved as followup of this feature:

1. create_entity can take more arguments. 
1. Texture
2. Reference to existing entity
3.  may beLocation features like orientation, velocity
4. A script to attach to the script
2. The addressable array for all the neighboring entities and the new entity should be updated to reflect the new entity. This can be done by adding a callback in ObjectScript and calling it when the space confirms the new entity is connected.

Screen Shots of new entities. The small cubes were created while running the "create.js" script.

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.