Re: [incquery-dev] xcore & eiq status

[Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxx>]

Thanks for checking it. About Eds comment, I repeat myself: "We have said to work amongst the first part; I have tried to look at how EMF does its things, but did not have the time to finish it yet." 

Zoli
On 2014.04.07., at 11:46, Tamás Szabó <tamas.szabo@xxxxxxxxx> wrote:

> Regarding plugin.xml content generation:
> I found out (again) that the problem is with the way we modify the contents of the plugin.xml. 
> The Ecore annotation will not have effect, because the original generated_package extension point lacks the @generated annotation once the IncQuery builder has worked on it. 
> Ed pointed out the following method: org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.mergePluginXML(String, String, String). Something similar should be used so that the annotation is kept intact. 
> 
> 2014.04.06. 9:49 keltezéssel, Ujhelyi Zoltán írta:
>> Hi,
>> 
>> Bug 419704 is not solved yet. It will require either throwing out the entire PDE-based plugin.xml loading, or accessing PDE internal stuff to work. We have said to work amongst the first part; I have tried to look at how EMF does its things, but did not have the time to finish it yet.
>> 
>> About (3): I would really like to have some data available of this problematic case.
>> 
>> Tamás: could you please turn on the tracing support of the platform in your run configuration for builders and execute the problematic case? The result would help a lot for determining why are we so slow.
>> 
>> I am attaching a screenshot with my corresponding settings (what is not visible, is not checked on the tracing page). If everything works, the log should contain some information like follows:
>> 
>> Sun Apr 06 09:44:33 CEST 2014 - [Worker-3] Invoking (INCREMENTAL_BUILD) on builder: XtextBuilder(headlessQueries.incquery; [])
>> Sun Apr 06 09:44:33 CEST 2014 - [Worker-3] Computing delta for project: headlessQueries.incquery
>> Sun Apr 06 09:44:33 CEST 2014 - [Worker-3] Finished computing delta, time: 1ms
>> Sun Apr 06 09:44:33 CEST 2014 - [Worker-3] /headlessQueries.incquery[*]: {}
>> Sun Apr 06 09:44:33 CEST 2014 - [Worker-3] Builder finished: XtextBuilder(headlessQueries.incquery; []) time: 2ms
>> 
>> 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
>> <Mail Attachment.png>
>> On 2014.04.05., at 17:53, Istvan Rath <rath@xxxxxxxxxx> wrote:
>> 
>>> Thanks for investigating this.
>>> 
>>> Zoli, did we do anything about the (problematic) plugin.xml generation? The last comment on https://bugs.eclipse.org/bugs/show_bug.cgi?id=419704 is from october last year. This might explain (2).
>>> 
>>> We also have a bugzilla (https://bugs.eclipse.org/bugs/show_bug.cgi?id=428015) that might be related to (3). Tamas, can you run a profiler to check what is taking a long time in this case?
>>> 
>>> 
>>> 
>>> On 05 Apr 2014, at 11:32, Tamás Szabó <tamas.szabo@xxxxxxxxx> wrote:
>>> 
>>>> Hi
>>>> 
>>>> A quick overview about the status of the xcore stuff:
>>>> (1) The @Ecore annotation doesn't seem to have any effect. If you specify a custom URI, it will not be written to the plugin.xml.
>>>> It is also interesting, that the runtime Xtext index contains the EPackage with the new custom URI. The original import in the
>>>> eiq files with the package URI "library" will not be valid anymore, you can (and should) use the new one, even if the plugin.xml contains the wrong entry.
>>>> This needs to be investigated with the help of Ed.
>>>> (2) I am not sure about the plugin.xml rewriting problems, I cant reproduce it deterministically. I tried to erase all the contents of the plugin.xml and invoke the builder again, and the contents have been written properly. Nevertheless, a full clean usually will result in the absence of the gen_package extension point definition and the query specification extension points. The derived feature extension points are always generated.
>>>> (3) Performance can be really poor in the xcore & EIQ scenario. Simply adding a new pattern will result in a long building time.
>>>> (4) When we reach the point that everything is generated properly into the plugin.xml, then the generated use case works just fine!
>>>> 
>>>> I will address (1), but I am going to need help with (2).
>>>> 
>>>> Cheers,
>>>> Tomi
>>>> _______________________________________________
>>>> 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