Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [incquery-dev] Query Explorer (and our tooling in general) is still badly broken

Thanks for waiting. About the branch: if you are confident that it is working right from the start (mostly :) ), add it to master. If you think it needs additional testing, put it into a separate branch or into a Gerrit code review.

Cheers,
Zoli
-- Zoltán Ujhelyi
https://www.inf.mit.bme.hu/en/members/ujhelyiz

Fault Tolerant Systems Research Group
Budapest University of Technology and Economics

On 2014.03.07., at 21:02, Tamás Szabó <tamas.szabo@xxxxxxxxx> wrote:

> Hi
> 
> What about the proposed change? Now that the new milestone build is it, I would like to give it a try, hopefully it will make QE faster.
> Should this be carried out in a separate branch?
> 
> Cheers,
> Tamas
> 
> 2014.02.20. 9:49 keltezéssel, Ujhelyi Zoltán írta:
>> Hi,
>> 
>> to me it was only a gut feeling what might be wrong - your guess is as good as mine, as we have no detailed measurements as proofs. :)
>> 
>> About removing the custom stuff from Query Explorer, it makes sense to me. Only a single thing: we are plannig to do a milestone build next week. It seems to me a good idea not to include this change before into master to have time to test it over; after that I am all for it. Implementation of course can begin even before that (either in Gerrit or in a branch).
>> 
>> Cheers,
>> Zoli
>> -- Zoltán Ujhelyi
>> https://www.inf.mit.bme.hu/en/members/ujhelyiz
>> 
>> Fault Tolerant Systems Research Group
>> Budapest University of Technology and Economics
>> 
>> On 2014.02.20., at 9:32, Tamás Szabó <tamas.szabo@xxxxxxxxx> wrote:
>> 
>>> Hi
>>> 
>>> I am not entirely convinced that the content provider is the problem. Here we are talking about the case when everything is reloaded again from the pattern model.
>>> It is an other thing, how we handle the update propagation in the treeviewer (1) with JFace databinding or (2) simply updating the model and calling refresh on the tree viewer.
>>> In our use case even the (1) option would not help, because the initialization takes a long time in both cases. Even if we have 1k+ or 3k+ match sets, updates in query results are propagated quickly to the view (no freezes).
>>> 
>>> On the other hand, rewriting the QE to work with IncQueryObservables is a good thing in my opinion, because it would result in a smaller codebase with a simpler solution. This is a thing that I am willing to do (what is your opinion?).
>>> 
>>> Cheers,
>>> Tomi
>>> 
>>> 2014.02.19. 14:55 keltezéssel, Ujhelyi Zoltán írta:
>>>> Hi,
>>>> 
>>>> I believe, the poor performance will have something to do with the manner we handle the content providers: if I understood the system correctly, it is not done incrementally but a full redraw is triggered in case of changes (I am not exactly sure about that, so I might be wrong here).
>>>> 
>>>> The only way to avoid that (I know about) is the way the Viewers content providers are implemented: 1) the initial content is loaded from the input, 2) change listeners are registered for the input, 3) in case of changes, the add/remove methods of the viewer is called, and 4) setInput is only called when the entire input becomes different.
>>>> 
>>>> Cheers,
>>>> Zoli
>>>> 
>>>> PS.: If you have the solution for the issue, then push it; I will merge it with my changes.
>>>> -- Zoltán Ujhelyi
>>>> https://www.inf.mit.bme.hu/en/members/ujhelyiz
>>>> 
>>>> Fault Tolerant Systems Research Group
>>>> Budapest University of Technology and Economics
>>>> 
>>>> On 2014.02.19., at 14:36, Tamás Szabó <tamas.szabo@xxxxxxxxx> wrote:
>>>> 
>>>>> (1) I have found the reason of this transition from "no matches" -> actual match sets.
>>>>> When the eiq file is modified, the patterns are re-registered for the loaded models. This registration is done by first unregistering the patterns and then registering them*. This process is called within a Display.getDefault.asyncExec() call, but the registration was again called in the same way (in a nested manner), this is why you could see the transition. Now I removed this unnecessary second call.
>>>>> 
>>>>> (2) I tried to set a max displayed match set size to 100 for a given matcher, but this doesn't seem to help at all. When you edit and save the eiq file the UI will freeze for 1-2 sec (the match set is 3k+ in size for CellInWorkSheet in my case).
>>>>> 
>>>>> * This may be expensive to do this all the time a SPACE is hit and saved. I am open to suggestions to determine cheaper what has changed (what specific pattern) without parsing the eiq file and reloading it.
>>>>> 
>>>>> 2014.02.19. 11:02 keltezéssel, Tamas Szabo írta:
>>>>>> Hi!
>>>>>> 
>>>>>> Yes, I will start with the 6th, because for the 2nd I will also need to contact Ed in the meantime.
>>>>>> 
>>>>>> Cheers,
>>>>>> Tomi
>>>>>> 
>>>>>> ----- Original Message -----
>>>>>> From: "Istvan Rath" <rath@xxxxxxxxxx>
>>>>>> To: "Incquery developer discussions" <incquery-dev@xxxxxxxxxxx>
>>>>>> Sent: Wednesday, February 19, 2014 10:55:55 AM
>>>>>> Subject: Re: [incquery-dev] Query Explorer (and our tooling in general) is	still badly broken
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> I have helped Zoli with reproducing issue 3.
>>>>>> 
>>>>>> Tomi, can you help with 2 and 6?
>>>>>> 
>>>>>> thanks!
>>>>>> Istvan
>>>>>> 
>>>>>> On 18 Feb 2014, at 22:12, Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxx> wrote:
>>>>>> 
>>>>>>> 2. Dynamic EMF mode is needed, because dependending on the fact whether the Xcore metamodel is loaded into the resource set or not, one of 4 (!) different instances of the EPackage is created and returned. The critical point is the MetamodelProvider#loadEPackage method, especially the first few rows, where we try to lookup the metamodel from the current resource set. Additionally, some of them also refer directly to the Ecore package, causing sometimes a mismatch between them in the indexer.
>>>>>>> 3. About the inconsistent state of the query explorer (Caused by: java.lang.IllegalStateException: Cannot edit query definition net.istvanrath.emfxcel.incquery.demo.CellInWorkSheet), can you provide some hints how to reproduce it? This is one of the new safeguards I have added to the specification creation process, but I have not seen any way to trigger it.
>>>>>>> 4. Builder execution frequency: when you turn off the autobuild, there is no guarantee that a project has not changed. Especially, as the Xtext index is updated in that phase that is used to handle cross-file and cross-project dependencies. I guess, this is an Xtext issue.
>>>>>>> 5. The weird cleaner exception means that the old version of the eiq file copied into bin is not what is expected anymore. What you have found, is a remainder of a previous type of solution - I have updated it to trigger a full clean.
>>>>>>> 6. QE inconsistency: I have witnessed it as well with the EMFxcel example; however, I am not convinced whether truly the widget is the bottleneck. Some more profiling is needed.
>>>>>>> 
>>>>>>> About point 2) I really have no idea how to proceed yet, but "luckily" this is truly an Xcore-specific issue, this will not happen in case of older models. Point 3) and 6) will need additional examination, but those at least are understandable issues.
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> Zoli
>>>>>>> -- Zoltán Ujhelyi
>>>>>>> https://www.inf.mit.bme.hu/en/members/ujhelyiz
>>>>>>> 
>>>>>>> Fault Tolerant Systems Research Group
>>>>>>> Budapest University of Technology and Economics
>>>>>>> 
>>>>>>> On 2014.02.16., at 21:15, Tamás Szabó <tamas.szabo@xxxxxxxxx> wrote:
>>>>>>> 
>>>>>>>> Let's just agree on that I will contact @Uzi beforehand, so we can catch up about what's left.
>>>>>>>> 
>>>>>>>> 2014.02.16. 21:14 keltezéssel, Tamás Szabó írta:
>>>>>>>>> I will also try to take a look at the xcore related problem next week.
>>>>>>>>> 
>>>>>>>>> 2014.02.16. 14:04 keltezéssel, Ujhelyi Zoltán írta:
>>>>>>>>>> Hi,
>>>>>>>>>> 
>>>>>>>>>> I have looked into the issue (again).
>>>>>>>>>> 
>>>>>>>>>> The annotation part should be fixed now in master (I have updated the corresponding code).
>>>>>>>>>> 
>>>>>>>>>> About the other issues, I am now strongly convinced that all (or at least most of them) are caused by a bad co-play between our Genmodel providing mechanism and Xcore-based metamodels. As I have already commented in https://bugs.eclipse.org/bugs/show_bug.cgi?id=428017, somehow the same EPackage gets loaded multiple times.
>>>>>>>>>> 
>>>>>>>>>> Today I will not have any more time to look into this, but I believe, this is specific to Xcore metamodels; we will not see this issue with other metamodels.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> About the performance: I have seen this with your EMFxcel example as well where there was no big instance model available, so maybe we have some other source of problem.
>>>>>>>>>> 
>>>>>>>>>> I will look into the other issues, but will not have time for it today.
>>>>>>>>>> 
>>>>>>>>>> Cheers,
>>>>>>>>>> Zoli
>>>>>>>>>> -- Zoltán Ujhelyi
>>>>>>>>>> https://www.inf.mit.bme.hu/en/members/ujhelyiz
>>>>>>>>>> 
>>>>>>>>>> Fault Tolerant Systems Research Group
>>>>>>>>>> Budapest University of Technology and Economics
>>>>>>>>>> 
>>>>>>>>>> On 2014.02.16., at 11:48, Istvan Rath <rath@xxxxxxxxxx> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Hi all,
>>>>>>>>>>> 
>>>>>>>>>>> a problems mentioned in the recent bugzilla (https://bugs.eclipse.org/bugs/show_bug.cgi?id=428016) are still present (as of the current master). I was working with the EMFxcel sample (https://github.com/ujhelyiz/EMF-IncQuery-Examples/tree/master/emfxcel) while discovering these issues.
>>>>>>>>>>> 
>>>>>>>>>>> - the @QueryExplorer annotation is still incorrectly handled (e.g. a message= assignment makes the pattern disappear from the QE, unless display=true is given)
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> I have also found some new issues:
>>>>>>>>>>> 
>>>>>>>>>>> - the emfxcel example seems to incorrectly need dynamic EMF mode (but only after trying to re-initialize the queries, it works fine on the first run):
>>>>>>>>>>> 
>>>>>>>>>>> !ENTRY org.eclipse.incquery.patternlanguage.emf.ui 4 0 2014-02-16 11:24:18.415
>>>>>>>>>>> !MESSAGE EMF-IncQuery encountered an error in processing the EMF model. This happened while trying to process new metamodel elements.
>>>>>>>>>>> 
>>>>>>>>>>> !STACK 0
>>>>>>>>>>> org.eclipse.incquery.runtime.base.exception.IncQueryBaseException: NsURI (http://www.eclipse.org/emf/2002/Ecore) collision detected between different instances of EPackages. If this is normal, try using dynamic EMF mode.
>>>>>>>>>>>   at org.eclipse.incquery.runtime.base.core.NavigationHelperContentAdapter.checkEPackage(NavigationHelperContentAdapter.java:595)
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> - incorrect error handling (causes no visible error reports in the EIQ editor, and makes the pattern disappear from the QE). Note: there was indeed an error in the EIQ, but the reporting was totally bogus and the whole system stopped working after this (see also next exception).
>>>>>>>>>>> 
>>>>>>>>>>> !ENTRY org.eclipse.ui 4 0 2014-02-16 11:14:47.301
>>>>>>>>>>> !MESSAGE Unhandled event loop exception
>>>>>>>>>>> !STACK 0
>>>>>>>>>>> org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.RuntimeException: org.eclipse.incquery.runtime.exception.IncQueryException: The following error occurred during the preparation of an EMF-IncQuery pattern matcher: Impossible to match pattern: exported pattern variable Nev can not be determined based on the pattern constraints. HINT: certain constructs (e.g. negative patterns or check expressions) cannot output symbolic parameters.)
>>>>>>>>>>>   at org.eclipse.swt.SWT.error(SWT.java:4397)
>>>>>>>>>>>   at org.eclipse.swt.SWT.error(SWT.java:4312)
>>>>>>>>>>>   at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:138)
>>>>>>>>>>>   at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3976)
>>>>>>>>>>>   at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3653)
>>>>>>>>>>>   at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1113)
>>>>>>>>>>>   at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
>>>>>>>>>>>   at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:997)
>>>>>>>>>>>   at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:138)
>>>>>>>>>>>   at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:610)
>>>>>>>>>>>   at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
>>>>>>>>>>>   at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:567)
>>>>>>>>>>>   at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
>>>>>>>>>>>   at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
>>>>>>>>>>>   at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
>>>>>>>>>>>   at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
>>>>>>>>>>>   at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
>>>>>>>>>>>   at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:354)
>>>>>>>>>>>   at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:181)
>>>>>>>>>>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>>>>>>   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>>>>>>>>>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>>>>>>>>>   at java.lang.reflect.Method.invoke(Method.java:597)
>>>>>>>>>>>   at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636)
>>>>>>>>>>>   at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591)
>>>>>>>>>>>   at org.eclipse.equinox.launcher.Main.run(Main.java:1450)
>>>>>>>>>>>   at org.eclipse.equinox.launcher.Main.main(Main.java:1426)
>>>>>>>>>>> Caused by: java.lang.RuntimeException: org.eclipse.incquery.runtime.exception.IncQueryException: The following error occurred during the preparation of an EMF-IncQuery pattern matcher: Impossible to match pattern: exported pattern variable Nev can not be determined based on the pattern constraints. HINT: certain constructs (e.g. negative patterns or check expressions) cannot output symbolic parameters.
>>>>>>>>>>>   at org.eclipse.incquery.tooling.ui.queryexplorer.handlers.RuntimeMatcherRegistrator.run(RuntimeMatcherRegistrator.java:74)
>>>>>>>>>>>   at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
>>>>>>>>>>>   at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
>>>>>>>>>>>   ... 24 more
>>>>>>>>>>> Caused by: org.eclipse.incquery.runtime.exception.IncQueryException: The following error occurred during the preparation of an EMF-IncQuery pattern matcher: Impossible to match pattern: exported pattern variable Nev can not be determined based on the pattern constraints. HINT: certain constructs (e.g. negative patterns or check expressions) cannot output symbolic parameters.
>>>>>>>>>>>   at org.eclipse.incquery.patternlanguage.emf.specification.SpecificationBuilder.getBodies(SpecificationBuilder.java:250)
>>>>>>>>>>>   at org.eclipse.incquery.patternlanguage.emf.specification.SpecificationBuilder.buildBodies(SpecificationBuilder.java:232)
>>>>>>>>>>>   at org.eclipse.incquery.patternlanguage.emf.specification.SpecificationBuilder.buildSpecification(SpecificationBuilder.java:196)
>>>>>>>>>>>   at org.eclipse.incquery.patternlanguage.emf.specification.SpecificationBuilder.getOrCreateSpecification(SpecificationBuilder.java:155)
>>>>>>>>>>>   at org.eclipse.incquery.tooling.ui.queryexplorer.util.QueryExplorerPatternRegistry.registerPatternModel(QueryExplorerPatternRegistry.java:129)
>>>>>>>>>>>   at org.eclipse.incquery.tooling.ui.queryexplorer.handlers.RuntimeMatcherRegistrator.registerPatternsFromPatternModel(RuntimeMatcherRegistrator.java:113)
>>>>>>>>>>>   at org.eclipse.incquery.tooling.ui.queryexplorer.handlers.RuntimeMatcherRegistrator.run(RuntimeMatcherRegistrator.java:71)
>>>>>>>>>>>   ... 26 more
>>>>>>>>>>> Caused by: org.eclipse.incquery.runtime.matchers.planning.QueryPlannerException: Impossible to match pattern: exported pattern variable Nev can not be determined based on the pattern constraints. HINT: certain constructs (e.g. negative patterns or check expressions) cannot output symbolic parameters.
>>>>>>>>>>>   at org.eclipse.incquery.runtime.matchers.psystem.basicdeferred.ExportedParameter.checkSanity(ExportedParameter.java:76)
>>>>>>>>>>>   at org.eclipse.incquery.runtime.matchers.psystem.PBodyNormalizer.checkSanity(PBodyNormalizer.java:127)
>>>>>>>>>>>   at org.eclipse.incquery.runtime.matchers.psystem.PBodyNormalizer.normalizeBody(PBodyNormalizer.java:58)
>>>>>>>>>>>   at org.eclipse.incquery.patternlanguage.emf.specification.SpecificationBuilder.getBodies(SpecificationBuilder.java:246)
>>>>>>>>>>>   ... 32 more
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> - encountered after previous problem:
>>>>>>>>>>> 
>>>>>>>>>>> ENTRY org.eclipse.ui 4 0 2014-02-16 11:15:44.687
>>>>>>>>>>> !MESSAGE Unhandled event loop exception
>>>>>>>>>>> !STACK 0
>>>>>>>>>>> org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.IllegalStateException: Cannot edit query definition net.istvanrath.emfxcel.incquery.demo.CellInWorkSheet)
>>>>>>>>>>>   at org.eclipse.swt.SWT.error(SWT.java:4397)
>>>>>>>>>>>   at org.eclipse.swt.SWT.error(SWT.java:4312)
>>>>>>>>>>>   at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:138)
>>>>>>>>>>>   at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3976)
>>>>>>>>>>>   at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3653)
>>>>>>>>>>>   at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1113)
>>>>>>>>>>>   at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
>>>>>>>>>>>   at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:997)
>>>>>>>>>>>   at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:138)
>>>>>>>>>>>   at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:610)
>>>>>>>>>>>   at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
>>>>>>>>>>>   at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:567)
>>>>>>>>>>>   at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
>>>>>>>>>>>   at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
>>>>>>>>>>>   at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
>>>>>>>>>>>   at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
>>>>>>>>>>>   at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
>>>>>>>>>>>   at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:354)
>>>>>>>>>>>   at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:181)
>>>>>>>>>>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>>>>>>   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>>>>>>>>>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>>>>>>>>>   at java.lang.reflect.Method.invoke(Method.java:597)
>>>>>>>>>>>   at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636)
>>>>>>>>>>>   at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591)
>>>>>>>>>>>   at org.eclipse.equinox.launcher.Main.run(Main.java:1450)
>>>>>>>>>>>   at org.eclipse.equinox.launcher.Main.main(Main.java:1426)
>>>>>>>>>>> Caused by: java.lang.IllegalStateException: Cannot edit query definition net.istvanrath.emfxcel.incquery.demo.CellInWorkSheet
>>>>>>>>>>>   at com.google.common.base.Preconditions.checkState(Preconditions.java:145)
>>>>>>>>>>>   at org.eclipse.incquery.runtime.api.impl.BaseQuerySpecification.checkMutability(BaseQuerySpecification.java:90)
>>>>>>>>>>>   at org.eclipse.incquery.runtime.matchers.psystem.PBody.checkMutability(PBody.java:194)
>>>>>>>>>>>   at org.eclipse.incquery.runtime.matchers.psystem.PBody.getOrCreateVariableByName(PBody.java:141)
>>>>>>>>>>>   at org.eclipse.incquery.patternlanguage.emf.specification.builder.EPMToPBody.getPNode(EPMToPBody.java:158)
>>>>>>>>>>>   at org.eclipse.incquery.patternlanguage.emf.specification.builder.EPMToPBody.preProcessParameters(EPMToPBody.java:211)
>>>>>>>>>>>   at org.eclipse.incquery.patternlanguage.emf.specification.builder.EPMToPBody.toPBody(EPMToPBody.java:107)
>>>>>>>>>>>   at org.eclipse.incquery.patternlanguage.emf.specification.SpecificationBuilder.getBodies(SpecificationBuilder.java:245)
>>>>>>>>>>>   at org.eclipse.incquery.patternlanguage.emf.specification.SpecificationBuilder.buildBodies(SpecificationBuilder.java:232)
>>>>>>>>>>>   at org.eclipse.incquery.patternlanguage.emf.specification.SpecificationBuilder.buildSpecification(SpecificationBuilder.java:196)
>>>>>>>>>>>   at org.eclipse.incquery.patternlanguage.emf.specification.SpecificationBuilder.getOrCreateSpecification(SpecificationBuilder.java:155)
>>>>>>>>>>>   at org.eclipse.incquery.tooling.ui.queryexplorer.util.QueryExplorerPatternRegistry.registerPatternModel(QueryExplorerPatternRegistry.java:129)
>>>>>>>>>>>   at org.eclipse.incquery.tooling.ui.queryexplorer.handlers.RuntimeMatcherRegistrator.registerPatternsFromPatternModel(RuntimeMatcherRegistrator.java:113)
>>>>>>>>>>>   at org.eclipse.incquery.tooling.ui.queryexplorer.handlers.RuntimeMatcherRegistrator.run(RuntimeMatcherRegistrator.java:71)
>>>>>>>>>>>   at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
>>>>>>>>>>>   at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
>>>>>>>>>>>   ... 24 more
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> I have encountered some additional issues related to the tooling in general:
>>>>>>>>>>> 
>>>>>>>>>>> - the builder runs (in my gut feeling) far too frequently. This is especially noticeable if you have many IncQuery projects open. I have seen several instances where disabling autobuild, editing one project, and then re-enabling autobuild triggers a build on _all_ incquery projects, which is very annoying.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> - the cleaner is prone to weird exceptions such as
>>>>>>>>>>> 
>>>>>>>>>>> 1 [Worker-5] ERROR org.eclipse.incquery  - Exception during Normal Clean!
>>>>>>>>>>> java.lang.IllegalStateException: Inconsistent pattern declaration found. Expected net.istvanrath.emfxcel.incquery.demo.IITOnlabosHallgato, found net.istvanrath.emfxcel.incquery.demo.NemVetteFelAzOnlabot.
>>>>>>>>>>>   at com.google.common.base.Preconditions.checkState(Preconditions.java:172)
>>>>>>>>>>>   at org.eclipse.incquery.patternlanguage.emf.ui.builder.CleanSupport.internalNormalClean(CleanSupport.java:175)
>>>>>>>>>>>   at org.eclipse.incquery.patternlanguage.emf.ui.builder.CleanSupport.normalClean(CleanSupport.java:149)
>>>>>>>>>>>   at org.eclipse.incquery.patternlanguage.emf.ui.builder.EMFPatternLanguageBuilderParticipant.build(EMFPatternLanguageBuilderParticipant.java:125)
>>>>>>>>>>> 
>>>>>>>>>>> - when you edit an EIQ file, save it, and while you wait for the QE to refresh its contents, there is a weird inconsistent state which gets displayed where no patterns have matches yet. This is noticeable if you are working with large results sets where refresh operations are sufficiently slow. On a related note, didn’t we have a feature whereby the contents of large (1000+) result sets are cropped so the tree viewer is not a bottle neck? This seems to be gone, making working with complex examples a big pain.
>>>>>>>>>>> 
>>>>>>>>>>> We need to fix these ASAP.
>>>>>>>>>>> 
>>>>>>>>>>> cheers
>>>>>>>>>>> Istvan
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Istvan Rath, PhD
>>>>>>>>>>> Research Fellow
>>>>>>>>>>> Fault Tolerant Systems Research Group
>>>>>>>>>>> Budapest University of Technology and Economics
>>>>>>>>>>> rath@xxxxxxxxxx
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> incquery-dev mailing list
>>>>>>>>>>> incquery-dev@xxxxxxxxxxx
>>>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/incquery-dev
>>>>>>>>>> _______________________________________________
>>>>>>>>>> incquery-dev mailing list
>>>>>>>>>> incquery-dev@xxxxxxxxxxx
>>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/incquery-dev
>>>>>>>> -- 
>>>>>>>> Tamás Szabó
>>>>>>>> Software Engineer
>>>>>>>> 
>>>>>>>> Tel.:   +49 711 342 191 0
>>>>>>>> Fax.:   +49 711 342 191 29
>>>>>>>> Mobil:  +49 171 565 416 9
>>>>>>>> Web:    www.itemis.de
>>>>>>>> Mail:   tamas.szabo@xxxxxxxxx
>>>>>>>> Skype:  szabta89
>>>>>>>> 
>>>>>>>> itemis AG
>>>>>>>> Niederlassung Süd
>>>>>>>> Meitnerstr. 10
>>>>>>>> 70563 Stuttgart
>>>>>>>> 
>>>>>>>> Rechtlicher Hinweis:
>>>>>>>> Registergericht: Amtsgericht Dortmund HRB 20621 | Sitz der Gesellschaft:
>>>>>>>> Lünen
>>>>>>>> Vorstand: Jens Wagener (Vorsitzender) | Wolfgang Neuhaus | Dr. Georg
>>>>>>>> Pietrek | Jens Trompeter | Sebastian Neus
>>>>>>>> Aufsichtsrat: Prof. Dr. Burkhard Igel (Vorsitzender) | Stephan Grollmann
>>>>>>>> | Michael Neuhaus
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> incquery-dev mailing list
>>>>>>>> incquery-dev@xxxxxxxxxxx
>>>>>>>> https://dev.eclipse.org/mailman/listinfo/incquery-dev
>>>>>>> _______________________________________________
>>>>>>> incquery-dev mailing list
>>>>>>> incquery-dev@xxxxxxxxxxx
>>>>>>> https://dev.eclipse.org/mailman/listinfo/incquery-dev
>>>>>> Istvan Rath, PhD
>>>>>> Research Fellow
>>>>>> Fault Tolerant Systems Research Group
>>>>>> Budapest University of Technology and Economics
>>>>>> rath@xxxxxxxxxx
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> incquery-dev mailing list
>>>>>> incquery-dev@xxxxxxxxxxx
>>>>>> https://dev.eclipse.org/mailman/listinfo/incquery-dev
>>>>>> _______________________________________________
>>>>>> incquery-dev mailing list
>>>>>> incquery-dev@xxxxxxxxxxx
>>>>>> https://dev.eclipse.org/mailman/listinfo/incquery-dev
>>>>> -- 
>>>>> Tamás Szabó
>>>>> Software Engineer
>>>>> 
>>>>> Tel.:   +49 711 342 191 0
>>>>> Fax.:   +49 711 342 191 29
>>>>> Mobil:  +49 171 565 416 9
>>>>> Web:    www.itemis.de
>>>>> Mail:   tamas.szabo@xxxxxxxxx
>>>>> Skype:  szabta89
>>>>> 
>>>>> itemis AG
>>>>> Niederlassung Süd
>>>>> Meitnerstr. 10
>>>>> 70563 Stuttgart
>>>>> 
>>>>> Rechtlicher Hinweis:
>>>>> Registergericht: Amtsgericht Dortmund HRB 20621 | Sitz der Gesellschaft:
>>>>> Lünen
>>>>> Vorstand: Jens Wagener (Vorsitzender) | Wolfgang Neuhaus | Dr. Georg
>>>>> Pietrek | Jens Trompeter | Sebastian Neus
>>>>> Aufsichtsrat: Prof. Dr. Burkhard Igel (Vorsitzender) | Stephan Grollmann
>>>>> | Michael Neuhaus
>>>>> 
>>>>> _______________________________________________
>>>>> incquery-dev mailing list
>>>>> incquery-dev@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/incquery-dev
>>>> _______________________________________________
>>>> incquery-dev mailing list
>>>> incquery-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/incquery-dev
>>> -- 
>>> Tamás Szabó
>>> Software Engineer
>>> 
>>> Tel.:   +49 711 342 191 0
>>> Fax.:   +49 711 342 191 29
>>> Mobil:  +49 171 565 416 9
>>> Web:    www.itemis.de
>>> Mail:   tamas.szabo@xxxxxxxxx
>>> Skype:  szabta89
>>> 
>>> itemis AG
>>> Niederlassung Süd
>>> Meitnerstr. 10
>>> 70563 Stuttgart
>>> 
>>> Rechtlicher Hinweis:
>>> Registergericht: Amtsgericht Dortmund HRB 20621 | Sitz der Gesellschaft:
>>> Lünen
>>> Vorstand: Jens Wagener (Vorsitzender) | Wolfgang Neuhaus | Dr. Georg
>>> Pietrek | Jens Trompeter | Sebastian Neus
>>> Aufsichtsrat: Prof. Dr. Burkhard Igel (Vorsitzender) | Stephan Grollmann
>>> | Michael Neuhaus
>>> 
>>> _______________________________________________
>>> incquery-dev mailing list
>>> incquery-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/incquery-dev
>> _______________________________________________
>> incquery-dev mailing list
>> incquery-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/incquery-dev
> 
> -- 
> Tamás Szabó
> Software Engineer
> 
> Tel.:   +49 711 342 191 0
> Fax.:   +49 711 342 191 29
> Mobil:  +49 171 565 416 9
> Web:    www.itemis.de
> Mail:   tamas.szabo@xxxxxxxxx
> Skype:  szabta89
> 
> itemis AG
> Niederlassung Süd
> Meitnerstr. 10
> 70563 Stuttgart
> 
> Rechtlicher Hinweis:
> Registergericht: Amtsgericht Dortmund HRB 20621 | Sitz der Gesellschaft:
> Lünen
> Vorstand: Jens Wagener (Vorsitzender) | Wolfgang Neuhaus | Dr. Georg
> Pietrek | Jens Trompeter | Sebastian Neus
> Aufsichtsrat: Prof. Dr. Burkhard Igel (Vorsitzender) | Stephan Grollmann
> | Michael Neuhaus
> 
> _______________________________________________
> incquery-dev mailing list
> incquery-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/incquery-dev



Back to the top