Eclipse Community Forums - RDF feed
https://www.eclipse.org/forums/
Eclipse Community ForumsGeneric pattern matcher invoking registered pattern from a bundle
https://www.eclipse.org/forums/index.php/mv/msg/1098533/1805525/#msg_1805525
I have a bunch of utility patterns registered by a bundle through the 'org.eclipse.viatra.query.runtime.queryspecification' extension point.
Then, in an eclipse instance with such bundle installed, I'm creating a vql file with a pattern that invokes (find) one of the utility patterns using its fully qualified name (the project has all the dependencies configured appropriately). All works well in the Viatra perspective, using the Query Results view.
If I try instead to use the query generic API to load that vql file and accomplish the same result, I get this stack trace:
java.lang.IllegalStateException: The status of the specification can only be set for uninitialized queries.
at org.eclipse.viatra.query.runtime.matchers.util.Preconditions.checkState(Preconditions.java:122)
at org.eclipse.viatra.query.patternlanguage.emf.specification.GenericEMFPatternPQuery.setStatus(GenericEMFPatternPQuery.java:194)
at org.eclipse.viatra.query.runtime.matchers.psystem.queries.BasePQuery.ensureInitialized(BasePQuery.java:192)
at org.eclipse.viatra.query.runtime.matchers.psystem.queries.BasePQuery.getTypeGuarantees(BasePQuery.java:156)
at org.eclipse.viatra.query.runtime.matchers.psystem.basicenumerables.PositivePatternCall.getTypesImpliedByCall(PositivePatternCall.java:65)
at org.eclipse.viatra.query.runtime.matchers.psystem.basicenumerables.PositivePatternCall.getImpliedJudgements(PositivePatternCall.java:57)
at org.eclipse.viatra.query.runtime.matchers.psystem.rewriters.PBodyNormalizer.eliminateInferrableTypes(PBodyNormalizer.java:188)
at org.eclipse.viatra.query.runtime.matchers.psystem.rewriters.PBodyNormalizer.normalizeBodyInternal(PBodyNormalizer.java:126)
at org.eclipse.viatra.query.runtime.matchers.psystem.rewriters.PBodyNormalizer.normalizeBody(PBodyNormalizer.java:106)
at org.eclipse.viatra.query.runtime.matchers.psystem.rewriters.PBodyNormalizer.rewrite(PBodyNormalizer.java:87)
at org.eclipse.viatra.query.runtime.matchers.psystem.rewriters.PDisjunctionRewriterCacher.rewrite(PDisjunctionRewriterCacher.java:58)
at org.eclipse.viatra.query.runtime.matchers.psystem.rewriters.PDisjunctionRewriter.rewrite(PDisjunctionRewriter.java:26)
at org.eclipse.viatra.query.runtime.rete.construction.plancompiler.ReteRecipeCompiler.compileProduction(ReteRecipeCompiler.java:257)
at org.eclipse.viatra.query.runtime.rete.construction.plancompiler.ReteRecipeCompiler.getCompiledForm(ReteRecipeCompiler.java:194)
at org.eclipse.viatra.query.runtime.rete.boundary.ReteBoundary.accessProductionTrace(ReteBoundary.java:349)
at org.eclipse.viatra.query.runtime.rete.matcher.ReteEngine.lambda$0(ReteEngine.java:204)
at org.eclipse.viatra.query.runtime.base.core.NavigationHelperImpl.coalesceTraversals(NavigationHelperImpl.java:1148)
at org.eclipse.viatra.query.runtime.emf.EMFQueryRuntimeContext.coalesceTraversals(EMFQueryRuntimeContext.java:117)
at org.eclipse.viatra.query.runtime.rete.matcher.ReteEngine.constructionWrapper(ReteEngine.java:247)
at org.eclipse.viatra.query.runtime.rete.matcher.ReteEngine.accessMatcher(ReteEngine.java:202)
at org.eclipse.viatra.query.runtime.rete.matcher.ReteEngine.getResultProvider(ReteEngine.java:518)
at org.eclipse.viatra.query.runtime.internal.apiimpl.ViatraQueryEngineImpl.getResultProviderInternal(ViatraQueryEngineImpl.java:578)
at org.eclipse.viatra.query.runtime.internal.apiimpl.ViatraQueryEngineImpl.getResultProviderInternal(ViatraQueryEngineImpl.java:565)
at org.eclipse.viatra.query.runtime.internal.apiimpl.ViatraQueryEngineImpl.getResultProvider(ViatraQueryEngineImpl.java:554)
at org.eclipse.viatra.query.runtime.internal.apiimpl.ViatraQueryEngineImpl.getMatcher(ViatraQueryEngineImpl.java:221)
at org.eclipse.viatra.query.runtime.internal.apiimpl.ViatraQueryEngineImpl.getMatcher(ViatraQueryEngineImpl.java:206)
In BasePQuery, line 191, setBodies sets the status to OK, but then line 192 fails when we're a GenericEMFPatternPQuery because the overridden setStatus does not allow to set OK again.
Is this a bug, or am I trying to do something unsupported through the query generic API?
tl;dr: I can successfully use the query generic API to load a vql file that invokes a pattern in another vql file in a different package in the same project. It fails if that package comes from a bundle.
Thanks,
Alessio]]>Alessio Di Sandro2019-04-16T17:40:46-00:00Re: Generic pattern matcher invoking registered pattern from a bundle
https://www.eclipse.org/forums/index.php/mv/msg/1098533/1805637/#msg_1805637
in general, the you describe is supported in general (e.g. the Query Results view also used the generic API of VIATRA), but when trying combine patterns from different sources, there might be some hoops to jump through that are non-trivial at first. For the simple cases, we provide the org.eclipse.viatra.query.patternlanguage.emf.util.PatternParser API, but that is not capable of handling all possible cases correctly, and some low-level Xtext magic might also be required.
The exception trace you have provided is very strange; we did a lot of testing to figure out the appropriate query specification initialization lifecycle. I'd very much like to have a reproducible example for the exception trace you mentioned, because that should not happen, and I could provide also some feedback on how to fix the original issue. What is important here (1) the concrete queries (e.g. the example may have something to do with the concrete pattern structure), (2) the way you initialize and use the parsing infrastructure, and (3) the version of VIATRA and Xtext you are using.
Best regards,
Zoltán]]>Zoltan Ujhelyi2019-04-19T09:40:48-00:00Re: Generic pattern matcher invoking registered pattern from a bundle
https://www.eclipse.org/forums/index.php/mv/msg/1098533/1806018/#msg_1806018
Sorry it took me this long to reply.
Attached are two projects that can replicate this: extract viatra.bundle in your development workspace, run as eclipse application, extract viatra.runtime in your runtime workspace, click the "Run Me" menu item in the top bar.
I'm running Eclipse 2019-03 with the Java 12 patches, Viatra 2.1.1.201902270913, Xtext 2.17.0.v20190304-1445.
Thanks,
Alessio]]>Alessio Di Sandro2019-04-30T14:17:14-00:00Re: Generic pattern matcher invoking registered pattern from a bundle
https://www.eclipse.org/forums/index.php/mv/msg/1098533/1806041/#msg_1806041
thanks for the reproducible example, it was really helpful for figuring out the underlying problem.
As I have believed, matcher initialization is fine in itself; the problem is that the query specification emitted by the SpecificationBuilder was erroneous. You could check for that using some code as follows (in line 68 of RunMe.java of your code):
if (spec.getInternalQueryRepresentation().getStatus() == PQueryStatus.ERROR) {
throw new Exception("Erroneous query specification");
}
The source of the parsing issue is that your resource set was not assigned to the project, so during parsing the referenced queries are not available. You could rely on an IResourceSetProvider accessed by a language-specific injector to set it up that should fix this issue (although I have not tried out whether it works or not).
However, if you want to execute queries defined in your workspace with some additional dependencies coming from an already installed bundle, a better approach might be to reuse the Query Specification Registry (this is the approach used by the Query Results view):
Hope this was helpful. If not, feel free to ask for clarification.
Best regards,
Zoltán]]>Zoltan Ujhelyi2019-05-01T11:00:11-00:00Re: Generic pattern matcher invoking registered pattern from a bundle
https://www.eclipse.org/forums/index.php/mv/msg/1098533/1806103/#msg_1806103
Quote:
As I have believed, matcher initialization is fine in itself; the problem is that the query specification emitted by the SpecificationBuilder was erroneous. You could check for that using some code as follows (in line 68 of RunMe.java of your code):
if (spec.getInternalQueryRepresentation().getStatus() == PQueryStatus.ERROR) {
throw new Exception("Erroneous query specification");
}
Not really, the status of the specification is OK after the builder.getOrCreateSpecification(pattern) call.
There seems to be a logical mistake in BasePQuery.ensureInitialized():
line 191 invokes setBodies, which sets the status to OK on line 205
line 192 sets the status to OK again, which fails for a GenericEMFPatternPQuery (because its overridden setStatus implementation runs the precondition check isMutable, line 194 of GenericEMFPatternPQuery)
Quote:
The source of the parsing issue is that your resource set was not assigned to the project, so during parsing the referenced queries are not available. You could rely on an IResourceSetProvider accessed by a language-specific injector to set it up that should fix this issue (although I have not tried out whether it works or not).
Maybe this would help, but I don't understand what I'm supposed to do.
Quote:
However, if you want to execute queries defined in your workspace with some additional dependencies coming from an already installed bundle, a better approach might be to reuse the Query Specification Registry (this is the approach used by the Query Results view):
Tried all of this, to no avail.
I ask for the 'viatra.bundle.importee' spec, find it, its status is OK, but then what do I do with it? I'm not supposed to invoke it directly, I just need it to be available as a dependency.
I tried passing it as an argument to the SpecificationBuilder constructor for the importer pattern, but it doesn't help.
Thanks,
Alessio]]>Alessio Di Sandro2019-05-02T16:12:31-00:00Re: Generic pattern matcher invoking registered pattern from a bundle
https://www.eclipse.org/forums/index.php/mv/msg/1098533/1806224/#msg_1806224
Quote:
Quote:
As I have believed, matcher initialization is fine in itself; the problem is that the query specification emitted by the SpecificationBuilder was erroneous. You could check for that using some code as follows (in line 68 of RunMe.java of your code):
if (spec.getInternalQueryRepresentation().getStatus() == PQueryStatus.ERROR) {
throw new Exception("Erroneous query specification");
}
Not really, the status of the specification is OK after the builder.getOrCreateSpecification(pattern) call.
When I have checked the code running, I received a clear ERROR status related to the fact that the query installed into Eclipse was not found during parsing - I have tested this behavior with both version 2.1.2 (latest release) and 2.2.0-SNAPSHOT (latest development build). In this sense, it is very strange that it behaves different in your case. The only difference is that I am using Java 11 instead of 12 (I don't have the latter one available).
Quote:
There seems to be a logical mistake in BasePQuery.ensureInitialized():
line 191 invokes setBodies, which sets the status to OK on line 205
line 192 sets the status to OK again, which fails for a GenericEMFPatternPQuery (because its overridden setStatus implementation runs the precondition check isMutable, line 194 of GenericEMFPatternPQuery)
About the logical mistake, I see what you mean, but that is not the root cause of the issue, as the error already happened before, but you are right, this should also be fixed. I will open a bug in Bugzilla for this case as well.
Quote:
Quote:
The source of the parsing issue is that your resource set was not assigned to the project, so during parsing the referenced queries are not available. You could rely on an IResourceSetProvider accessed by a language-specific injector to set it up that should fix this issue (although I have not tried out whether it works or not).
Maybe this would help, but I don't understand what I'm supposed to do.
I don't have any clean example for this case, but you have to access the language injector (see http://koehnlein.blogspot.com/2012/11/xtext-tip-how-do-i-get-guice-injector.html for related ideas), and then inject an instance of IResourceSetProvider to your class. Then use this provider to access a ResourceSet that is set up with the classpath of the runtime project.
Quote:
Quote:
However, if you want to execute queries defined in your workspace with some additional dependencies coming from an already installed bundle, a better approach might be to reuse the Query Specification Registry (this is the approach used by the Query Results view):
Tried all of this, to no avail.
I ask for the 'viatra.bundle.importee' spec, find it, its status is OK, but then what do I do with it? I'm not supposed to invoke it directly, I just need it to be available as a dependency.
I tried passing it as an argument to the SpecificationBuilder constructor for the importer pattern, but it doesn't help.
As for the importer pattern, not the importee. If it is in your workspace in a VIATRA Query project, the index-based registry loader should load it.
Best regards,
Zoltán]]>Zoltan Ujhelyi2019-05-06T12:25:36-00:00Re: Generic pattern matcher invoking registered pattern from a bundle
https://www.eclipse.org/forums/index.php/mv/msg/1098533/1806244/#msg_1806244
Quote:
When I have checked the code running, I received a clear ERROR status related to the fact that the query installed into Eclipse was not found during parsing - I have tested this behavior with both version 2.1.2 (latest release) and 2.2.0-SNAPSHOT (latest development build). In this sense, it is very strange that it behaves different in your case. The only difference is that I am using Java 11 instead of 12 (I don't have the latter one available).
I don't know what to say.
With the two projects I attached, I get an OK, i.e. the spec for the importer pattern loads fine. It then errors at the engine.getMatcher(spec) call.
Quote:
As for the importer pattern, not the importee. If it is in your workspace in a VIATRA Query project, the index-based registry loader should load it.
Nope, the registry (QuerySpecificationRegistry.getInstance()) only contains the patterns from bundles, not from the viatra query projects in the current workspace.
I'll either try your other injector suggestion, or look at the code behind the query view interface, since it works there.
Thanks,
Alessio]]>Alessio Di Sandro2019-05-06T17:56:15-00:00Re: Generic pattern matcher invoking registered pattern from a bundle
https://www.eclipse.org/forums/index.php/mv/msg/1098533/1806246/#msg_1806246
first of all, sorry for all the troubles, but I am mostly at a loss at what could be the source of the problem. I'm trying to figure out what might be the source of the issue, but I did not see such an issue before.
Alessio Di Sandro wrote on Mon, 06 May 2019 17:56
Quote:
When I have checked the code running, I received a clear ERROR status related to the fact that the query installed into Eclipse was not found during parsing - I have tested this behavior with both version 2.1.2 (latest release) and 2.2.0-SNAPSHOT (latest development build). In this sense, it is very strange that it behaves different in your case. The only difference is that I am using Java 11 instead of 12 (I don't have the latter one available).
I don't know what to say.
With the two projects I attached, I get an OK, i.e. the spec for the importer pattern loads fine. It then errors at the engine.getMatcher(spec) call.
I had another go, and also installed Java 12, but my results were consistent with my earlier experiments: I put `viatra.bundle` to my host Eclipse; then loaded `viatra.runtime` to the runtime. When everything compiled, I have executed the RunMe command, where I have seen that the importer pattern is erroneous because it cannot parse the importee...
If it behaves differently at you, then something works really differently on your computer - however, I have no idea in what way.
Quote:
As for the importer pattern, not the importee. If it is in your workspace in a VIATRA Query project, the index-based registry loader should load it.
Nope, the registry (QuerySpecificationRegistry.getInstance()) only contains the patterns from bundles, not from the viatra query projects in the current workspace.[/quote]