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