Thanks. I found the QVTo standalone Bugzilla as I prepared to raise
a Bugzilla with my own inferior solution. Pity its not in the
While QVTo continues use the Ecore binding, the various Xtext
activities are irrelevant to QVTo. However, once the Pivot model is
promoted and all the elements of tool auto-generation from a
specification are in place, it may be appropriate to provide the
accurate models for the QVT specification and then auto-generate
large parts of the QVT tooling from the specification models. This
is my plan for QVTd.
The Xtext to LPG conversion is a useful part of this tooling since
it will achieve a 10-fold reduction in parser size, a corresponding
reduction in JIT start-up time, and perhaps a 2-fold improvement in
parsing time, without losing the benefits of the very compact Xtext
grammar and the associated auto-generation of many editor
The CST used by the Xtext to LPG conversion will be an
Xtext-friendly CST, so that the auto-generated name lookup and CST
to AST conversions will be equally applicable to usage within the
Xtext editor using ANTLR or in the OCL compiler using LPG. I see no
prospect of providing an upgrade path for the existing CST and with
auto-generation of everything using the CST, I see no point in
preserving the old CST.
I don't understand what you mean by "Could you please point me where
QVTo *.xtex is persisted?". Perhaps you're being confused by "QVTo:
*.xtext -> *.xtext.XBNF"; my use of QVTo as an M2M transformation
tool to transform from an Xtext file/model to further models. You
can find the QVTo transformations in the o.e.o.examples.xtext2lpg
plugin in the bug/369123a branch.
On 01/03/2012 16:51, Sergey Boyko wrote:
Could you please describe in more details what is "Xtext to LPG"
means for QVTo. Could you please point me where QVTo *.xtex is
About QVTo statndalone execution; look at http://wiki.eclipse.org/M2M/QVTO/New_and_Noteworthy/Helios#Milestone_5
On Wed, Feb 29, 2012 at 11:56 AM, Ed
I made a relatively small Xtext grammar change and suddenly
got stupid syntax errors, probably because a magic
backtracking precedence flipped. I therefore started updating
the 'equivalent' LPG grammar to look for a conflict and
realized that the time had come to look at automated Xtext to
LPG conversion; it's relatively easy.
I've therefore developed/am developing a Tx cascade
QVTo: *.xtext -> *.xtext.XBNF to get a fully referential
EBNF model from the Xtext CST
QVTo: *.xtext.XBNF -> *.xtext.normal.XBNF to convert to a
disjunct of conjuncts BNF
QVTo: *.normal.XBNF -> *.inline.XBNF to re-inline
non-recursive references that were originally from a single
Acceleo: *.inline.XBNF -> *.g, *.gi
(XBNF is Xtext BNF, i.e BNF with model annotations)
Currently plausible KWLexer and Parser grammars are generated,
Lexer still todo; the Xtext and LPG styles are very different.
Action code still to do; should be easy with all the model
Unfortunately there is no QVTo standalone support so I also
had to develop that and the corresponding MWE integration.
The build scripts are in the build plugin. The transformations
in the examples.xtext2lpg plugin.
Since only the build plugin has QVTo dependencies and neither
of the above plugins are in the Tools build, I don';t think
that there is any releng impact.
mdt-ocl.dev mailing list
found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1913 / Virus Database: 2114/4843 - Release Date: