Matcher algorithms about gumtree

[jrfaller]

Hi!

Thanks for reporting an issue about GumTree.

This is really strange, Matchers.getInstance().getMatcher(src, dst) should return an instance of ClassicGumtree, and not ZsMatcher. Can you provide me the code to reproduce the problem, against the latest commit on the develop branch?

ClassicMatcher is the only (almost 😉) production ready matcher furnished in GumTree, all the others are only implemented for evaluation purpose. However if there is a infinite loop in ZsMatcher,
I am really interested about the test case since this matcher is used under the hood by ClassicGumtree.

Cheers!

[onhate]

Thanks for you response @jrfaller

It is possible that Matchers.getInstance().getMatcher(src, dst) is returning ClassicGumtree but calling ZsMatcher, I thought it was returning just ZsMatcher because that's what I see on stacktrace when it goes infinite loop.

using these files (I know they are very peculiar).
https://gist.github.com/onhate/21bd5764fcf333051d05e221e7063a5e

and this snippet

TreeContext src = Generators.getInstance().getTree(left.toString());
TreeContext dst = Generators.getInstance().getTree(right.toString());

Matcher matcher = Matchers.getInstance().getMatcher(src.getRoot(), dst.getRoot());
matcher.match();

TreeClassifier classifier = new RootAndLeavesClassifier(src, dst, matcher);

[jrfaller]

OK thanks for the files!

The problem seems to come from the variable LZD containing a binary string because when I remove it, it works like a charm.

I am not sure though why it's a problem for ZsMatcher, unless it comes from the levenstein distance that is computed under the hood.

[jrfaller]

Actually, the method used to return label similarity is this one :

return 1D - StringMetrics.qGramsDistance().compare(n1.getLabel(), n2.getLabel());