[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[incquery-dev] PSystem/Builder refactor - part 2
|
Hi,
today I have achieved a working version of the "pattern-less" IncQuery runtime. The changes were aimed at avoiding instantiating stuff in runtime with Pattern objects, instead IQuerySpecification objects are used now throughout the system. Some testing/review would be very helpful (yes, it is a pretty big change set, but this was the smallest self-contained set I could come up with), as the change is quite big - on the other hand, I do not consider this stable, and any decision is open to debate.
The changes are pushed into Gerrit: https://git.eclipse.org/r/#/c/20346/
A more detailed changelog
* A new builder for query specifications is created with SpecificationBuilder (in runtime project)
* This class maintains a set of Pattern->QuerySpecification mapping (patterns are represented with fully qualified names), and encapsulates the older EPMToPSystem classes functionality).
* The class also encompasses the previously engine-level validations (it is the last component that knows the original pattern objects)
* An interface named PQuery is introduced, that became the super interface of IQuerySpecification. These two interfaces can be used for accessing query metadata.
* It is possible that matchers/matches currently maintain metainformation that is not forwarded to the corresponding specification, but that is something I have missed.
* Additionally, among these lines https://bugs.eclipse.org/bugs/show_bug.cgi?id=423279 has also been fixed in these changes.
* All query specifications needs to be regenerated. Some internal changes require this.
* The changes were having some rippling effect throughout the codebase. Luckily, only minor modifications were required, with the following exceptions:
* The entire Viewers API was having patterns as its central element. This needed some heavy refactorings - it seemed to work for me, but needs extensive testing.
* The Query Explorer also needs some experimenting. Seems working, but some rough edges may remain.
Known issues
* Private patterns are not supported in generated code for now. This is a major regression, but it makes no sense to fix it at this stage. I will not merge these changes into master until the code generator has been correctly updated to also support these cases.
* Generated code still relies on patterns. It is bound to be changed, but I was aiming for a testable version.
After incorporating anything you might come up related to this changeset, I will continue with
1) Making the runtime project indeed Xtext-independent
2) Updating the generator to use this new API in the generated code
3) After the generator is correctly updated, globaleiq.xmi will be removed
Cheers,
Zoli
PS.: I have an additional commit (as a different change set) pushed to gerrit: https://git.eclipse.org/r/#/c/20345/ - this deals with extension duplication in Kepler that came forth deterministicly after the refactoring, but I am not confident enough to release it into master. If you check out the other review into your eclipse instance, this will also be included by default.
-- Zoltán Ujhelyi
https://www.inf.mit.bme.hu/en/members/ujhelyiz
Fault Tolerant Systems Research Group
Budapest University of Technology and Economics