[00:43] <hazmat> jimbaker, thanks for the review
[00:52] <jimbaker> hazmat, np, it was a very easy review to do since i was so familiar with that bit of code. nice solution!
[00:54] <hazmat> jimbaker, its a transient solution..
[00:54] <hazmat> jimbaker, there's some more work to be done on the scheduler
[00:54] <jimbaker> hazmat, oh sure, i know you want to avoid label exp
[00:54] <hazmat> jimbaker, right now its dropping events on the floor on error
[00:54] <hazmat> i still want to do late expansion.. but at the point of consumption
[00:54] <jimbaker> hazmat, right
[00:55] <hazmat> within the scheduler... its too hard to rewire it to not reduce things.. but perhaps at the point of consumption..
[00:56] <hazmat> right now the scheduler feeding into the hook execution, is destructive.. so its possible to miss events on a hook error..
[00:56] <hazmat> sigh
[00:56] <hazmat> much to do
[00:56] <hazmat> thanks again
[00:58] <jimbaker> hazmat, so reduce at consumption time?
[00:59] <hazmat> jimbaker, i'm not sure yet.. i was thinking expanding inline to the scheduler run method..
[00:59] <hazmat> reducing at consumption time turns it from O(1) to O(n)
[01:00] <hazmat> the problem with expanding inline, is that if the join hook fails, we want the change hook queued up..
[01:03] <jimbaker> hazmat, i don't think i understand your point re O(1) vs O(n)
[01:04] <jimbaker> is it always going to look at every subsequent event in that case? once reduced, it's gone
[01:04] <hazmat> jimbaker, when we reduce as we pickup events, we have at most 1 previous event
[01:05] <hazmat> if we reduce as we feed to the executor, we can have n events
[01:06] <jimbaker> hazmat, i still don't see the arg unfortunately
[01:07] <jimbaker> also we are not exactly dealing with a large number of events even if this were true
[01:07] <hazmat> jimbaker, its not a very good arg, the numbers here make it rather irrelevant
[01:07] <jimbaker> hazmat, agreed