#development
- w
witty-crayon-22786
06/15/2018, 1:40 AM... so, hm. it's related to the graph. - w
witty-crayon-22786
06/15/2018, 1:41 AMbecause if what you want to do is display N things, what i should do is walk deep enough into the graph to collect N running things. - r
rough-minister-58256
06/15/2018, 1:41 AMI guess fundamentally the most natural visualization here is roots -> (all graph execution tasks at deepest depth in the stack)? (basically, your super wide graphviz renders -> terminal w/ animated replacement of nodes vs drawn out).. but we need to group that in a way that makes it easier to display. - r
rough-minister-58256
06/15/2018, 1:41 AMsince there can be many more roots than can be represented in a terminal - w
witty-crayon-22786
06/15/2018, 1:42 AMyea, right. - w
witty-crayon-22786
06/15/2018, 1:42 AMbut that's sortof the idea behind the threshold - w
witty-crayon-22786
06/15/2018, 1:42 AMyou don't go all the way to the leaves with a threshold - r
rough-minister-58256
06/15/2018, 1:44 AMand my thinking there was - since we’re effectively replacing nodes inplace and polling for UI display, going all the way to the leaves isn’t a problem - in fact its more accurate - w
witty-crayon-22786
06/15/2018, 1:44 AMwell, that's threshold 0... and i believe that that would update too rapidly to be useful. - r
rough-minister-58256
06/15/2018, 1:45 AMyeah, depending on the polling interval in the ui you may never see tiny things - w
witty-crayon-22786
06/15/2018, 1:45 AMthe opposite - w
witty-crayon-22786
06/15/2018, 1:46 AMyou'd only ever see tiny things - w
witty-crayon-22786
06/15/2018, 1:46 AM(...with no threshold) - r
rough-minister-58256
06/15/2018, 1:47 AMi would expect tiny things to not dominate that? - w
witty-crayon-22786
06/15/2018, 1:47 AM...or. are you saying collect all running leaves, and then take top K by duration ? - r
rough-minister-58256
06/15/2018, 1:47 AMtiny things execute fast - then they’re gone. we’ve done hundreds/thousands of display updates by then - r
rough-minister-58256
06/15/2018, 1:48 AMI think: collect all running leaves at the top most depth in the execution stack for a given root - r
rough-minister-58256
06/15/2018, 1:49 AMwell, fundamentally - w
witty-crayon-22786
06/15/2018, 1:49 AM... i think this might be a "graph flow" problem, heh - w
witty-crayon-22786
06/15/2018, 1:49 AM - w
witty-crayon-22786
06/15/2018, 1:50 AMthe analogy that makes me think this is that the more time spent in a particular subgraph, the more you want to display things there - w
witty-crayon-22786
06/15/2018, 1:50 AMso sortof like focus flowing down from the roots through edges weighted with their runtime - r
rough-minister-58256
06/15/2018, 1:52 AM🤔 - a
aloof-angle-91616
06/15/2018, 1:52 AMwhy would we not want to make the display of rules something with at least knobs to tweak for the rule designer themselves - a
aloof-angle-91616
06/15/2018, 1:53 AMi can tell you maybe that some long-running command isn't important, and a whole bunch of rules related to that command are also going to take a minimal amount of time, and aren't doing anything that would be useful for the user to see - w
witty-crayon-22786
06/15/2018, 1:53 AMrule output is something else - r
rough-minister-58256
06/15/2018, 1:53 AMseems like maybe its just “deepest depth edges”? - a
aloof-angle-91616
06/15/2018, 1:53 AMand i feel like a system to accumulate settings like that transitively for rules would be more interesting than trying to effectively display the "best" of a massive pool of options according to some statistical model - a
aloof-angle-91616
06/15/2018, 1:53 AMnot talking about rule output - w
witty-crayon-22786
06/15/2018, 1:55 AMregardless of what someone puts on their rule, if it is taking a very long time to run, we should render it.