Skip to main content
[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

Back to the top