various fixes. Fixed some issues with vector join.
Experimented with types to enable "join" that mandates a certain subclass of VectTerm implementation (i.e. ensure that implementation-compatible vectors are being joined.

Hmmm, if Terms all had a 'builder' instance, then maybe I could use this.type to ensure that you could only join vectors from the same builder instance?

Other changes to 'initialised' concept on VectTerm, though I now realise I have to add this to hasValue to work 100% correctly.
trade categorise test
Added initialised to hasValue interface and provided simple implementation.
next stage is to replace the old vector.ReshapeSignal.newColumnHasValue mechanism and check we are unit test covered
Massive overhaul to initialised state. This simplifies some data structures, but more importantly adds safe, guaranteed semantics to avoiding applying transforms to uninitialised cells.
 Fixed an independent bug I'd introduced that would fire a reduction twice for slice-after buckets
Ok, looks like it makes more sense for continuous reductions (fold) to not count as initialised until the first event is added.
This avoids us emitting an event on initialisation of a reduce bucket.
The motivating use-case was when plotting a MultiTerm of cumulative event count, we'd get an initial count=0 event before time begins.
 I'm still somewhat undecided on this one
Done the type signatures for an approach for defining arbitrary bucketing of unions of event sources.
e.g. a class to summarise book and trade events, which can be used to emit 'curve' data at different resolutions.
Maybe this is overkill, after all, I could always use join or take to build a tuple that is then sent into a Reduce.add call, and unpacked. Maybe I'm premature-optimising here, but I don't really like tuples, it's too easy to get the properties muddled up if you're sending in a load of simple data types. The major advantage is that the event firing semantics are not messed up, we get to clearly distinguish between when different input sources fire (because they are bound to different 'addX' methods)
Motivated by wanting to get standard Mekon 'Function' integrated and driven by Scespet style streams, I've come up with two slightly different approaches.
one drives a Function from a given source stream, using a higher order function to apply values into the target bucket.
the other approach is to allow standard Mekon functions to be used in a 'slice' context, but the function does all its source event acquisition and manual env.addListener. This would be how I'm going to do something like a feed curve stats collector.

See RealTradeTests for examples

In order to support, I had to add getTriggers support to the stupid event graph impl, and added EventSource intiialisation to the event manager.
Motivated by wanting to get standard Mekon 'Function' integrated and driven by Scespet style streams, I've come up with two slightly different approaches.
one drives a Function from a given source stream, using a higher order function to apply values into the target bucket.
the other approach is to allow standard Mekon functions to be used in a 'slice' context, but the function does all its source event acquisition and manual env.addListener. This would be how I'm going to do something like a feed curve stats collector.

See RealTradeTests for examples

In order to support, I had to add getTriggers support to the stupid event graph impl, and added EventSource intiialisation to the event manager.