Home » Archived » EMF-IncQuery » Reflective IncQueryEngine
Reflective IncQueryEngine [message #1074634] |
Sat, 27 July 2013 09:36 |
|
Hi everyone,
I'm trying to set up a IncQueryEngine to work reflectively using a globalEiqModel.xmi and a target model only (no generated code), but without much success. To demonstrate the problem, in the linked project [1], I've deleted src-gen and the related extensions in plugin.xml and disabled the IncQuery and Xtext builders so that they are not regenerated automatically. Running PluggedInTest as a plugged-in test when src-gen is not around throws an exception; if I enable the builder everything works well. I've tried to see how QueryExplorer does it but haven't had much luck. Any thoughts would be really appreciated.
Cheers,
Dimitris
[1] https://dl.dropboxusercontent.com/u/5636547/org.eclipse.epsilon.emc.incquery.demo.zip
|
|
| |
Re: Reflective IncQueryEngine [message #1074643 is a reply to message #1074639] |
Sat, 27 July 2013 10:09 |
|
Hi Zoltán,
Thanks for your quick reply! As advised, I've replaced the following lines of code in my plugged in test
IQuerySpecification<? extends IncQueryMatcher<? extends IPatternMatch>> querySpecification
= QuerySpecificationRegistry.getOrCreateQuerySpecification(patternModel.getPatterns().get(0));
System.err.println(querySpecification.getMatcher(engine).getAllMatches().size());
with this one
System.err.println(engine.getMatcher(patternModel.getPatterns().get(0)).getAllMatches().size());
but I'm now getting a different NPE:
java.lang.NullPointerException
at org.eclipse.xtext.common.types.util.JavaReflectAccess.getRawType(JavaReflectAccess.java:107)
at org.eclipse.xtext.common.types.util.JavaReflectAccess.getMethod(JavaReflectAccess.java:73)
at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.invokeOperation(XbaseInterpreter.java:920)
at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.invokeOperation(XbaseInterpreter.java:916)
Any thoughts?
Cheers,
Dimitris
|
|
|
Re: Reflective IncQueryEngine [message #1074732 is a reply to message #1074643] |
Sat, 27 July 2013 15:39 |
Istvan Rath Messages: 59 Registered: July 2009 |
Member |
|
|
Hi Dimitris,
our documentation has some details and example code on getting the reflective query invocation API to work, at http://wiki.eclipse.org/EMFIncQuery/UserDocumentation/API/Advanced . If you have some time, could you verify that these techniques work/do not work for you? (In case they don't work, I'll check and correct the docs.)
As for the NPE, unfortunately it seems to come from the Xbase interpreter. As this is an external component w.r.t. our codebase, it would help a lot if you could specify exactly which version of Xtext and IncQuery you are using.
Finally, two important remarks:
- running patterns with check expressions in interpreted mode is much slower than the compiled mode, so for performance benchmarks the compiled version is definitely recommended. (This only applies to check expressions, though.)
- I have looked into your example code:
pattern EXX() {
nr == count find ECWA()
check (nr > 1)
}
can be replaced by the much more performant
pattern EXX() {
find ECWA()
}
as a find implies that it has to have at least one match (which is semantically equivalent to your formulation).
HTH, cheers
Istvan
|
|
|
Re: Reflective IncQueryEngine [message #1074765 is a reply to message #1074732] |
Sat, 27 July 2013 18:08 |
Joost van Pinxten Messages: 51 Registered: November 2012 |
Member |
|
|
Hi Istvan,
Istvan Rath wrote on Sat, 27 July 2013 11:39Hi Dimitris,
our documentation has some details and example code on getting the reflective query invocation API to work, at http://wiki.eclipse.org/EMFIncQuery/UserDocumentation/API/Advanced . If you have some time, could you verify that these techniques work/do not work for you? (In case they don't work, I'll check and correct the docs.)
Thanks for this information; we have indeed been looking at the advanced standalone usage of the IncQuery engine. We will have another go, hopefully next week.
Istvan Rath wrote on Sat, 27 July 2013 11:39
As for the NPE, unfortunately it seems to come from the Xbase interpreter. As this is an external component w.r.t. our codebase, it would help a lot if you could specify exactly which version of Xtext and IncQuery you are using.
It seems that the Xbase interpreter is not correctly injected, which might have to do with the environment that we're instantiating the IQ Engine in. Although I don't know the exact version right now, we were running this example in Kepler, so most probably the Xtext version was 2.4.2. We were using the stable 0.7.0 release of IncQuery.
Istvan Rath wrote on Sat, 27 July 2013 11:39
Finally, two important remarks:
- running patterns with check expressions in interpreted mode is much slower than the compiled mode, so for performance benchmarks the compiled version is definitely recommended. (This only applies to check expressions, though.)
- I have looked into your example code:
pattern EXX() {
nr == count find ECWA()
check (nr > 1)
}
can be replaced by the much more performant
pattern EXX() {
find ECWA()
}
as a find implies that it has to have at least one match (which is semantically equivalent to your formulation).
HTH, cheers
Istvan
This is not equivalent! Your 'find'-example is equivalent to:
pattern EXX() {
nr == count find ECWA();
check (nr >= 1); // notice the greater-equal here
}
In our simple pattern, we have chosen that we need more than one occurrence before we want to match.
Cheers, thanks for looking into it and pointing out the possible performance issues.
Joost
[Updated on: Sat, 27 July 2013 18:09] Report message to a moderator
|
|
| |
Re: Reflective IncQueryEngine [message #1074787 is a reply to message #1074780] |
Sat, 27 July 2013 19:38 |
Zoltan Ujhelyi Messages: 392 Registered: July 2015 |
Senior Member |
|
|
Hi,
I had some time to experiment with your project, and now I know why it is not working, and can provide workarounds (but sadly, no real solution).
The problem is that our code that copies the patterns into the globaleiqmodel file, does not copy well the check expressions. For the generated code, it does not matter, as the compiled expressions are registered using the org.eclipse.incquery.runtime.xexpressionevaluator extension point that our runtime finds. When you are turning off all generated code, this compiled Xbase expressions are not found, so the system tries to parse the (incorrect) check expressions.
What might work as workaround:
* Do not turn off the code generation, or at least provide the expressionevaluator. In this case, you can still instantiate the generic matcher.
* You can try to parse the original .eiq file. Sadly because of a late change in Xtext 2.4 we had to provide a quick and hacky solution for the IncQuery parsing, which means, you need to have GUI dependencies to parse the eiq files with check expressions, which is most likely not what you want. If you are interested in that solution, check the test setup of our patternlanguage test project (http://git.eclipse.org/c/incquery/org.eclipse.incquery.git/tree/tests/org.eclipse.incquery.patternlanguage.emf.tests).
However, my real question is, what are you trying to achieve with this interesting setup? If possible, I would be glad to offer a more stable alternative.
Cheers,
Zoltán
|
|
|
Re: Reflective IncQueryEngine [message #1074791 is a reply to message #1074787] |
Sat, 27 July 2013 19:51 |
|
Hi Zoltán,
Thanks for looking into this. GUI dependencies are not a blocker at these stage so we'll try the second solution. We're trying to build a driver for Epsilon [1] that will enable languages of the platform to consume the results of IncQuery pattern matching so that identified matches can be used in further model management operations (e.g. model-to-text/model-to-model transformation etc).
Cheers,
Dimitris
[1] http://eclipse.org/epsilon/
|
|
| |
Re: Reflective IncQueryEngine [message #1074795 is a reply to message #1074792] |
Sat, 27 July 2013 20:04 |
|
Hi Zoltán,
We'd prefer to also provide support for using IncQuery in a reflective mode - if possible - so that users don't have to keep launching new Eclipse instances during development.
Cheers,
Dimitris
|
|
| |
Re: Reflective IncQueryEngine [message #1075365 is a reply to message #1074765] |
Mon, 29 July 2013 10:00 |
Istvan Rath Messages: 59 Registered: July 2009 |
Member |
|
|
Hi guys,
Quote:This is not equivalent! Your 'find'-example is equivalent to:
pattern EXX() {
nr == count find ECWA();
check (nr >= 1); // notice the greater-equal here
}
In our simple pattern, we have chosen that we need more than one occurrence before we want to match.
True! I have overlooked that detail. Anyway, your pattern could be expressed as
pattern EXX() {
find ECWA(A);
find ECWA(B);
A != B;
}
which will likely yield better performance than the check()-based variant. (This depends on some other factors such as the composition of your instance model and the number of matches ECWA() actually has, but it might be worth a look if you are optimizing for performance.)
Another similar trick could be to omit the IsInEcore() construct entirely, and restrict the matching scope to the resource of your instance model (instead of the entire resourceset) - this would make this "manual" filtering for Ecore elements (which, I presume, are in a different resource than your instance model) unnecessary.
Quote: I suspect that the versions of Xtext and Xbase (both 2.4.2) we're using is not the problem as the QueryExplorer (which I assume also works in a reflective manner) works fine for this example. We did use [1] as our starting point but without much success I'm afraid.
As Zoltan wrote, the source of the issue is in our tooling, namely that the serialization of Xbase expressions to globalEiqModel.xmi is not correct. As the Query Explorer does not use this, but parses and loads the .eiq resources directly through Xtext, it is not affected by the issue. I will extend the headless example and its corresponding wiki page [1] to illustrate how this should be done from Java code, which will hopefully help you to resolve the issue.
Istvan
|
|
| | | |
Re: Reflective IncQueryEngine [message #1076441 is a reply to message #1076123] |
Wed, 31 July 2013 12:04 |
Istvan Rath Messages: 59 Registered: July 2009 |
Member |
|
|
Hi guys,
I have some good news. http://wiki.eclipse.org/EMFIncQuery/UserDocumentation/API/Advanced#Loading_EIQ_resources_programmatically now shows a technique that works on my setup, the most important part is
// Xtext resource magic -- this is needed for EIQs
new EMFPatternLanguageStandaloneSetup()
{
@Override
public Injector createInjector() {
return Guice.createInjector(new GeneratorModule());
}
}.createInjectorAndDoEMFRegistration();
// use a trick to load Pattern models from a file
ResourceSet resourceSet = new ResourceSetImpl();
URI fileURI = URI.createPlatformResourceURI("test/src/test/test.eiq", false);
Resource patternResource = resourceSet.getResource(fileURI, true);
As Zoltan has predicted before, this code (through GeneratorModule) brings in some UI dependencies, which you'll have to live with until we resolve (the newly created) https://bugs.eclipse.org/bugs/show_bug.cgi?id=414121
Another issue to take into consideration is that in EIQs loaded like this, there seem to be some minor differences (e.g. FQNs vs names, see the bug above for details) which have to be taken into consideration depending on what you want to do with your Pattern instances. (Pattern matching with IncQuery works just fine.)
I have also fixed another bug that involved the XBase interpreter, so I recommend to try this technique on a recent CI build of IncQuery. (It should also get into the integration builds soon.)
Let me know if this helps,
cheers
Istvan
|
|
|
Re: Reflective IncQueryEngine [message #1077819 is a reply to message #1076441] |
Fri, 02 August 2013 07:28 |
|
Hi Istvan,
Thanks! I've tried this with the latest CI build and it works fine. The only glitch is that I'm getting a few error markers on my .eiq file which I don't understand and which don't seem to be affecting the runtime behaviour (see linked screenshot). Any thoughts?
Cheers,
Dimitris
|
|
| | | |
Re: Reflective IncQueryEngine [message #1080681 is a reply to message #1077866] |
Tue, 06 August 2013 08:52 |
|
Hi Istvan,
Thanks for looking into this! I turned on/off the IncQuery and Xtext builders a couple of times but that was about it, I think. In any event, the error has now disappeared so we can move forward with this.
Cheers,
Dimitris
|
|
| | | |
Re: Reflective IncQueryEngine [message #1116307 is a reply to message #1116293] |
Wed, 25 September 2013 08:11 |
Joost van Pinxten Messages: 51 Registered: November 2012 |
Member |
|
|
Good morning Istvan,
There is no such documentation or tutorial yet, but the functionality would be comparable (i.e. an alternative) to what the Epsilon Pattern Language [1] (chapter 11) offers.
As for as a tutorial, if you'd want to try it out, use an Eclipse with IQ 0.8.0.201309231452 and Epsilon (+ Epsilon EMF integration) 1.1.0.201309221936. Then simply checkout the org.eclipse.epsilon.emc.incquery and org.eclipse.epsilon.emc.incquery.demo projects from the EpsilonLabs repo [2]. Open the .incquery project and run a new Eclipse instance; open the .incquery.demo project and run the test.launch (or the test.eol manually). This should show a single match in the console: (i.e. "Match found: C1").
The only thing necessary to use an existing IncQuery project is the place of the pattern file (.eiq) and the model to execute the patterns on; they are then automatically available in any EOL script. As Epsilon already supports many interesting stuff for EMF classes, most functionality was almost automatically available for IncQuery matches!
One of the idea's we've had, is to be able to bind the Epsilon operations onto the appearance/disappearance of pattern matches (through for example the EVM), such that Epsilon can benefit from the incremental approach of the IncQuery matching engine. However, this is quite a bit more involved and, unfortunately, we can't spend a lot of time on this integration at the moment.
Cheers,
Joost
[1] http://eclipse.org/epsilon/doc/book/
[2] http://code.google.com/p/epsilonlabs/
[Updated on: Wed, 25 September 2013 09:16] Report message to a moderator
|
|
|
Re: Reflective IncQueryEngine [message #1243920 is a reply to message #1074634] |
Tue, 11 February 2014 16:45 |
Zoltan Ujhelyi Messages: 392 Registered: July 2015 |
Senior Member |
|
|
Hi all,
today I have finally outlined how the generic API (and the eiq file loading) will work in IncQuery 0.8.
Basically, there is no need for the UI dependencies anymore, and the hack István found is also not required.
On the other hand, the structure of IncQuery projects changed very much: there is no more globaleiqmodel.xmi version of the patterns (at all), and the generated code is much different, so a migration step is needed for version 0.8 (see https://wiki.eclipse.org/EMFIncQuery/Releases/MigrateTo0.8).
On the other hand, as seen in https://wiki.eclipse.org/EMFIncQuery/UserDocumentation/API/Advanced#Initializing_matchers_and_accessing_results it is possible to load eiq files without any problems.
We plan to release an integration build containing this new features this week, and a milestone build for the 1st of March.
If you have any questions, or suggestions about this approach, we will try our best to answer them.
Cheers,
Zoltán
|
|
|
Goto Forum:
Current Time: Wed Dec 04 13:42:17 GMT 2024
Powered by FUDForum. Page generated in 0.07030 seconds
|