<div dir="ltr"><div dir="ltr"><br></div><br class="gmail-Apple-interchange-newline">This. Is. Amazing. Thank you so much for taking the time to assemble this mail! I agree with everything stated above -- I think I'm as ready as I'll ever be to put together a nice looking proposal.<div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 4 Apr 2019 at 22:22, Artem Dergachev <<a href="mailto:noqnoqneo@gmail.com">noqnoqneo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF">
    I kinda gathered some understanding of the problem and the solution
    and trying to come up with some sort of a plan, and for that purpose
    i'm trying to step back from "we should totally do this cool
    technique" towards a more "adult", "boring" point of view that
    consists in asking, "what *do* we need to do?".<br>
    <br>
    For now i'm seeing that the work on this problem can be decomposed
    into three chunks:<br>
    <br>
    (1) Collect slicing criteria from various sources,<br>
    (2) Perform slicing to discover data and control dependencies,<br>
    (3) Use information about dependencies to improve the bug report.<br>
    <br>
    Chunk (3) sounds straightforward: we just enable or disable path
    pieces based on information we already have. I don't fully
    understand how it'll go, but i don't see any unknowns here.<br>
    <br>
    Chunk (1) sounds like a large amount of routine, repetitive work:
    convert sources of slicing criteria, such as checkers, to the new
    system one-by-one. There is certain amount of known unknowns here:
    some sources may be tricky to take advantage of (eg.,
    liveness-related sources), some may put stress on the checkers.<br>
    <br>
    Chunk (2) is the research-intensive part: it has an easy 80%
    solution (AST matching based detection that has already been
    implemented and proved useful for one of the checkers) and an idea
    to improve upon it by implementing a more sophisticated analysis.<br>
    <br>
    Because chunk (2) is research-intensive, we need experimental data
    that we currently don't have. In order to avoid spending a lot of
    time on something that isn't going to work, we should try to gather
    that data as soon as possible in our plan.<br></div></blockquote><div><br></div><div>Umm, what do you mean under "data"? Like, proving how the examples I showed would be solved by this technique?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
    <br>
    Because chunk (1) is repetitive, we don't need to implement it
    completely; we can pick one or two sources and get them right.<br>
    <br>
    Therefore here's the plan that emerges:<br>
    i. Pick one or two slicing criteria sources and implement them.<br>
    ii. Implement a simple AST-based algorithm for discovering
    dependencies.<br>
    iii. Apply the information produced by that algorithm to the bug
    report.<br>
    iv. Run the updated analyzer on real-world codebases and see what
    problems remain.<br>
    v. Implement solutions to these problems.<br>
    <br>
    Solutions on step v. may or may not be about coding a more
    sophisticated slicing algorithm. They might as well be improvements
    in chunk (1), i.e. discovering more slicing criteria, or they may be
    about a "horizontal" improvement in the existing primitive algorithm
    (eg., cover more forms of control flow or different variants of data
    dependencies, which should have been a separate chunk).<br>
    <br>
    That's roughly how i imagine it. <br></div></blockquote><div> <br></div></div></div></div>