[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [m2m-atl-dev] Feature proposal: ATL research VM with built-in composition support
|
Hi Dennis,
Answers below:
Le 22/06/2011 11:15, Dennis Wagelaar a écrit :
Dear fellow ATL devs,
The EMFTVM has been approved and committed to the ATL CVS repository. Please read the README.TXT file in the org.eclipse.m2m.atl.emftvm.compiler plug-in to find out how to bootstrap the ATL-to-EMFTVM compiler (this does not happen automatically!).
Thanks !
Just one remark: I saw that you also added emftvm plugins in the atl
feature.
This is not the problem, but as we just released ATL 3.2 - without
emftvm - I will have to:
* remove references to emftvm in the feature
* tag and branch ATL 3.2 plugins from CVS HEAD (for future ATL 3.2
maintenance releases)
* restore emftvm references in the feature, so emftvm will be part of
the next ATL 3.3 release
I will do it asap (it also implies for me to update the releng system to
allow build of 3.2 branch etc etc...), anyway you don't have anything to
do about that.
N.B. I've comitted the *.test projects under "plugins" instead of "tests". Is this a problem?
It would have been be better in tests, for an organization purpose, but
I don't think this will be a problem for touchy things like releng.
N.B.2. Checkstyle won't accept the ATL configuration ("cannot initialize module TreeWalker - TreeWalker is not allowed as a parent of FileLength"). Do any of you have problem with using the ATL checkstyle config?
The ATL configuration has been defined and older version of checkstyle.
I use 4.4.2
http://sourceforge.net/projects/eclipse-cs/files/Eclipse%20Checkstyle%20Plug-in/v4.4.2/
Unfortunately the older configurations are not recognized by newer
versions of checkstyle :-/
Kind regards,
Dennis Wagelaar
Thanks again for your work !
Best Regards,
William
Op 12-05-11 19:48, Dennis Wagelaar schreef:
Hello Andreza,
The new VM should be available in CVS shortly after approval (+- 1 week?).
Release will take longer, as this must be done together with the main ATL
releases. The PMC_Approved flag has been set by now, so the code is one step
further in the IP process. I'm not sure what other steps are necessary, and
how long the entire approval process will take, though.
If you really want to try out the code already, you can take a look at:
http://soft.vub.ac.be/soft/research/mdd/emftvm
N.B. The Eclipse committed code will *not* be compatible with the above
version of EMFTVM due to rebranding (package names, plug-in IDs, etc.), and
the above version will be discontinued as soon as EMFTVM is part of ATL.
Regards,
Dennis
On 12/05/11 15:21, Andreza Vieira wrote:
Hello Dennis Wagelaar,
That's a very good proposal.
After your proposal is accepted, when can the users obtain the new version
of the ATL VM? At moment, I'm using the actual ATL VM version and I'll have
to do some changes in my project to support the new version.
Best regrads.
Andreza
2011/5/12 Dennis Wagelaar<dennis.wagelaar@xxxxxxxxx
<mailto:dennis.wagelaar@xxxxxxxxx>>
Dear fellow ATL devs,
As you may have noticed by now, I've submitted a feature proposal to IPzilla
and Bugzilla. The feature concerns a new VM for ATL (EMFTVM), but also other
rule-based transformations languages, that incorporates composition (rule
inheritance, module superimposition) as an integral part. Most notable
features of EMFTVM are:
- New bytecode format that includes a notion of rules (just like Java
bytecode
includes the notion of classes)
- Support for multiple rule inheritance at load-time (explicit rules
allow for
late super-rule lookup)
- Support for module import with rule/helper redefinition (i.e. module
superimposition) that *combines* with rule inheritance
- Support for closures (in the form of nested code blocks), which can be
used
for OCL's higher-order operations (collect, select, ...), but also ease
compilation (1 ATL expression = 1 EMFTVM code block), and open the door for
fine-grained concurrency (continuations, futures)
- Includes a lazy implementation of OCL collections
- ATL compiler written in ATL (new bytecode format is an EMF metamodel)
The reason I'd like to include EMFTVM with the ATL SDK, is to provide a
research VM in which we can try out new features. The current ATL VM
architecture makes it near impossible to change the bytecode format.
EMFTVM's
bytecode format can be changed more easily: the compiler is written in ATL,
not AGC, so there is no hard dependency on the bytecode format. Also, the
intention is to have only *one* implementation of the EMFTVM bytecode
format.
ATL features tested out on EMFTVM in this way can later be included in the
mainstraim compilers/VMs (e.g. multiple rule inheritance, closures, lazy
collections). Other features rely on a change in the bytecode format (e.g.
late super-rule lookup), and cannot be ported to the mainstraim VMs.
CAN YOU GUYS take a look at the IPzilla entry
(https://dev.eclipse.org/ipzilla/show_bug.cgi?id=5171) and mark the
*PMC_Approved* flag if you agree that EMFTVM should be included with ATL?
Thanks already!
Kind regards,
Dennis Wagelaar
_______________________________________________
m2m-atl-dev mailing list
m2m-atl-dev@xxxxxxxxxxx<mailto:m2m-atl-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/m2m-atl-dev
--
Andreza Vieira
_______________________________________________
m2m-atl-dev mailing list
m2m-atl-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2m-atl-dev
_______________________________________________
m2m-atl-dev mailing list
m2m-atl-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2m-atl-dev
begin:vcard
fn:William Piers
n:Piers;William
org:Obeo
email;internet:william.piers@xxxxxxx
title:MDA Consultant
version:2.1
end:vcard