<div style="font-family: arial, helvetica, sans-serif"><font size="2">On Sun, Jun 17, 2012 at 9:46 PM, Evgeny Panasyuk <span dir="ltr"><<a href="mailto:evgeny.panasyuk@gmail.com" target="_blank">evgeny.panasyuk@gmail.com</a>></span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div class="im">
    17.06.2012 22:44, Manuel Klimek wrote: <br>
    <blockquote type="cite">
      <div style="font-family:arial,helvetica,sans-serif"><font size="2">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000"> I see different
                approaches to implement such kind of tool:<br>
                1. Naive and straightforward way: just as external tool
                to ASTMatchers, same method that I used in example
                above. Such approach would result in some "knowledge"
                duplication, i.e. for each predicate it would be
                additional some code in predicate-generation tool.<br>
                2. More complex way, but with some "knowledge" reuse
                from ASTMatchers. That approach would require
                re-describing predicates with some higher/another
                abstraction, what would allow us to generate both
                predicates and predicates-generation stuff from one
                source of "knowledge". I am not sure if such approach
                could be done in general, requires some research.</div>
            </blockquote>
            <div><br>
            </div>
            <div>My hunch is that for (2) the matchers would be
              sufficiently different from what they are now, that it
              would end up like (1) anyway - insert the obvious
              disclaimer that I might be wrong etc etc here :)</div>
          </div>
        </font></div>
    </blockquote></div>
    Yes, (2) would require re-implementation of matchers in other terms.
    But I think API of matchers will be not changed.<div class="im"><br>
    <br>
    <blockquote type="cite">
      <div style="font-family:arial,helvetica,sans-serif"><font size="2">
          <div class="gmail_quote">
            <div>At least for a first step I think (1) is the way to go
              - once we have more experience with how the stuff is used,
              we can then try to figure out how to generalize it...</div>
          </div>
        </font></div>
    </blockquote>
    <br></div>
    Yes, I fully agree. (1) is a good step to start with, at least for
    prototype.<div class="im"><br>
    <br>
    <blockquote type="cite">
      <div style="font-family:arial,helvetica,sans-serif"><font size="2">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000">
                <div>
                  <blockquote type="cite">
                    <div style="font-family:arial,helvetica,sans-serif"><font size="2">
                        <div class="gmail_quote">
                          <div>I don't know whether you're aware, but in
                            the tooling branch there's also a
                            proof-of-concept implementation for dynamic
                            matcher generation, and it might make sense
                            to base your stuff on that.</div>
                        </div>
                      </font></div>
                  </blockquote>
                  <br>
                </div>
                Are you talking about dynamic parseMatcher (as in
                ast-query example)?<br>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>Yep, that one...</div>
          </div>
        </font></div>
    </blockquote>
    <br></div>
    Thank you for note.<div class="im"><br>
    <br>
    <blockquote type="cite">
      <div style="font-family:arial,helvetica,sans-serif"><font size="2">
          <div class="gmail_quote">
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000"> Or maybe about some
                interactive (maybe gui) tool for building predicates? I
                remember that Chandler mentioned about something similar
                at <a href="http://www.youtube.com/watch?v=yuIOGfcOH0k&t=27m56s" target="_blank">http://www.youtube.com/watch?v=yuIOGfcOH0k&t=27m56s</a>
                <br>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>Now we're talking the next step :) Yea, having a GUI
              would be *great* (and just so we're clear: with GUI I mean
              a web page :P)</div>
          </div>
        </font></div>
    </blockquote>
    <br></div>
    And maybe AST database optimized for fast predicate matches :)<br></div></blockquote><div><br></div><div>For small projects this might be interesting - for us the question is how that would scale - we've found parsing the C++ code to be actually an interesting way to scale the AST, for the small price of needing up 3-4 seconds per TU (on average). Denormalizing the AST itself produces a huge amount of data, and denormalizing even more seems like a non-starter.</div>
<div><br></div><div>Thoughts?</div><div>/Manuel</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    <br>
    Best Regards,<br>
    Evgeny<br>
  </div>

</blockquote></div><br></font></div>