Software Development

Another update on Project V. I'm done events. This was a really ugly and intrusive change. It's one of those things that I rant against. I did it as cleanly as I could and implemented in the way I've mentioned in the past to keep two versions of the code accessible. One version triggers an event. The other does not. The reason for this is that member functions often want to do modifications without triggering events mid-way through. So the no event methods come in handy.

This is one of the things that really does not work anything like the real world. In real life, you can have someone watch the entity in question, and if it changes, the person can report back with that change. Or you can simply have a device do the work for you.

On the other hand, with memory you can't just monitor a memory location. In theory you could, but it'd be awfully inefficient. The processor can tell when a 4K (or 1MB) page has been written to. This is necessary for virtual memory. Certain memory profilers on Linux use this method as well to know if your memory has been corrupted or if you have any bad pointers. But allocating 4K (or 1MB) for each object is ridiculous.

What I have to do is actually insert some code before and after the changes take place. For the events that get called right away, I have imposed a restriction that you may not modify the entity in question within the event handler. However, delayed event handlers may do whatever they like.

IOW, immediate event handlers are for monitoring purposes only. Delayed event handlers are used if you need to update the component network itself.

I think this is a good compromise and ensures that there are no recursive event triggers.

Another problem I encountered was deletion of entities within the component network. I don't want to trigger events and then find out that entity in question isn't even around anymore. Actually, this is what made me consider delayed events in the first place. Not only delayed events, but delayed deletion. Deletion will do everything you would think. It separates itself from any other nodes and triggers all the events that these actions would generate. But it doesn't actually delete the node itself. So all events will at least get access to the entity itself which includes its name and ID. Once all delayed events have been handled, all items queued for deletion are deleted.

And yes, I'm well aware that this is one case where GC would have been helpful. But I don't want to be dependent on a GC when I build the native compiler. It's simply not necessary.

Next up on the agenda is completing the building of networks. I've had most of the code done for a while now. But with events, I can keep the GUI automatically updated of any changes. This is what was slowing me down. I did not want to have to tell the GUI of every change. How am I supposed to know what GUI components require updates? Instead, GUI components register an event handler within the Project V component network. That way, each GUI component will be in charge of keeping itself updated. Much cleaner and much easier to maintain. Also reduces coupling between GUI components and the Project V component network.

(Note that GUI components are visual like buttons and Project V components are computational nodes like addition).

After I can build networks, I'll built the single core runtime engine which is already done. I just have to update a few things on it to reflect the changes I've made since then.

Then multicore runtime engine... then distributed runtime engine... then the WORLD!