Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » VIATRA » Generic pattern matcher invoking registered pattern from a bundle
Generic pattern matcher invoking registered pattern from a bundle [message #1805525] Tue, 16 April 2019 17:40 Go to next message
Alessio Di Sandro is currently offline Alessio Di SandroFriend
Messages: 4
Registered: April 2019
Junior Member
Hi,

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
Re: Generic pattern matcher invoking registered pattern from a bundle [message #1805637 is a reply to message #1805525] Fri, 19 April 2019 09:40 Go to previous messageGo to next message
Zoltan Ujhelyi is currently offline Zoltan UjhelyiFriend
Messages: 379
Registered: July 2015
Senior Member
Hi Alessio,

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
Re: Generic pattern matcher invoking registered pattern from a bundle [message #1806018 is a reply to message #1805637] Tue, 30 April 2019 14:17 Go to previous messageGo to next message
Alessio Di Sandro is currently offline Alessio Di SandroFriend
Messages: 4
Registered: April 2019
Junior Member
Hi Zoltan,

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
Re: Generic pattern matcher invoking registered pattern from a bundle [message #1806041 is a reply to message #1806018] Wed, 01 May 2019 11:00 Go to previous messageGo to next message
Zoltan Ujhelyi is currently offline Zoltan UjhelyiFriend
Messages: 379
Registered: July 2015
Senior Member
Hi Alessio,

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");
}

For providing a better feedback for this issue, I have opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=546885; and for providing an easier API for detecting on the code side whether the parsing failed https://bugs.eclipse.org/bugs/show_bug.cgi?id=546886.

--

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):

* Start up the Xtext Index based registry loader (by accessing it, as an example, see https://git.eclipse.org/c/viatra/org.eclipse.viatra.git/tree/query/plugins/org.eclipse.viatra.query.patternlanguage.emf.ui/src/org/eclipse/viatra/query/tooling/ui/queryresult/QueryResultView.java#n125)
* After the loader is initialized, you could ask for any query specification by name from the registry.
* Make sure you check whether the returned query specification is erroneous or not.

Hope this was helpful. If not, feel free to ask for clarification.

Best regards,
Zoltán

[Updated on: Wed, 01 May 2019 11:00]

Report message to a moderator

Re: Generic pattern matcher invoking registered pattern from a bundle [message #1806103 is a reply to message #1806041] Thu, 02 May 2019 16:12 Go to previous messageGo to next message
Alessio Di Sandro is currently offline Alessio Di SandroFriend
Messages: 4
Registered: April 2019
Junior Member
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.

Quote:
For providing a better feedback for this issue, I have opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=546885; and for providing an easier API for detecting on the code side whether the parsing failed https://bugs.eclipse.org/bugs/show_bug.cgi?id=546886.


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):

* Start up the Xtext Index based registry loader (by accessing it, as an example, see https://git.eclipse.org/c/viatra/org.eclipse.viatra.git/tree/query/plugins/org.eclipse.viatra.query.patternlanguage.emf.ui/src/org/eclipse/viatra/query/tooling/ui/queryresult/QueryResultView.java#n125)
* After the loader is initialized, you could ask for any query specification by name from the registry.
* Make sure you check whether the returned query specification is erroneous or not.


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
Re: Generic pattern matcher invoking registered pattern from a bundle [message #1806224 is a reply to message #1806103] Mon, 06 May 2019 12:25 Go to previous messageGo to next message
Zoltan Ujhelyi is currently offline Zoltan UjhelyiFriend
Messages: 379
Registered: July 2015
Senior Member
Hi Alessio,

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):

* Start up the Xtext Index based registry loader (by accessing it, as an example, see https://git.eclipse.org/c/viatra/org.eclipse.viatra.git/tree/query/plugins/org.eclipse.viatra.query.patternlanguage.emf.ui/src/org/eclipse/viatra/query/tooling/ui/queryresult/QueryResultView.java#n125)
* After the loader is initialized, you could ask for any query specification by name from the registry.
* Make sure you check whether the returned query specification is erroneous or not.


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
Re: Generic pattern matcher invoking registered pattern from a bundle [message #1806244 is a reply to message #1806224] Mon, 06 May 2019 17:56 Go to previous messageGo to next message
Alessio Di Sandro is currently offline Alessio Di SandroFriend
Messages: 4
Registered: April 2019
Junior Member
Hi Zoltan,

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
Re: Generic pattern matcher invoking registered pattern from a bundle [message #1806246 is a reply to message #1806244] Mon, 06 May 2019 19:26 Go to previous message
Zoltan Ujhelyi is currently offline Zoltan UjhelyiFriend
Messages: 379
Registered: July 2015
Senior Member
Hi Alessio,

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]

I am sorry, I have forgotten that we decided not to include the index-based parsed patterns, because it might cause surprising results. For this reason, the Query Registry view initializes a specialized view that also contains the runtime patterns. More details can be found at: https://git.eclipse.org/c/viatra/org.eclipse.viatra.git/tree/query/plugins/org.eclipse.viatra.query.patternlanguage.emf.ui/src/org/eclipse/viatra/query/tooling/ui/queryregistry/QueryRegistryTreeInput.xtend#n41

I hope this will help you to fix your issue.

Best regards,
Zoltán
Previous Topic:Tutorial: Batch transformation
Next Topic:Using JUnit to test Viatra transformations
Goto Forum:
  


Current Time: Tue Nov 24 04:25:22 GMT 2020

Powered by FUDForum. Page generated in 0.02354 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top