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