/srv/irclogs.ubuntu.com/2012/03/03/#juju-dev.txt

hazmatjimbaker, thanks for the review00:43
jimbakerhazmat, np, it was a very easy review to do since i was so familiar with that bit of code. nice solution!00:52
hazmatjimbaker, its a transient solution..00:54
hazmatjimbaker, there's some more work to be done on the scheduler00:54
jimbakerhazmat, oh sure, i know you want to avoid label exp00:54
hazmatjimbaker, right now its dropping events on the floor on error00:54
hazmati still want to do late expansion.. but at the point of consumption00:54
jimbakerhazmat, right00:54
hazmatwithin the scheduler... its too hard to rewire it to not reduce things.. but perhaps at the point of consumption..00:55
hazmatright now the scheduler feeding into the hook execution, is destructive.. so its possible to miss events on a hook error..00:56
hazmatsigh00:56
hazmatmuch to do00:56
hazmatthanks again00:56
jimbakerhazmat, so reduce at consumption time?00:58
hazmatjimbaker, i'm not sure yet.. i was thinking expanding inline to the scheduler run method..00:59
hazmatreducing at consumption time turns it from O(1) to O(n)00:59
hazmatthe problem with expanding inline, is that if the join hook fails, we want the change hook queued up..01:00
jimbakerhazmat, i don't think i understand your point re O(1) vs O(n)01:03
jimbakeris it always going to look at every subsequent event in that case? once reduced, it's gone01:04
hazmatjimbaker, when we reduce as we pickup events, we have at most 1 previous event01:04
hazmatif we reduce as we feed to the executor, we can have n events01:05
jimbakerhazmat, i still don't see the arg unfortunately01:06
jimbakeralso we are not exactly dealing with a large number of events even if this were true01:07
hazmatjimbaker, its not a very good arg, the numbers here make it rather irrelevant01:07
jimbakerhazmat, agreed01:07

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!