Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » MXF proposal : collaboration
| MXF proposal : collaboration [message #132409] |
Fri, 23 January 2009 06:03  |
Eclipse User |
|
|
|
Originally posted by: didier.vojtise_nospam_k.irisa.fr
Hello
We just received the notification of the new MXF (Model eXecution
Framework) project proposal which sound great.
(we strongly believe in executable metamodelling applications)
Actually, this project seems closely related to the existing Kermeta
project (project web page : www.kermeta.org) of the INRIA French
research institute (www.inria.fr)
This is an open source project (EPL) that started in 2005 (project forge
: http://gforge.inria.fr/projects/kermeta/).
Kermeta provides an operational semantics to MOF (just like MXF plan to
do) and provides
an eclipse based workbench (seamlessly uses ecore) (includes editors,
various views, intrepreter, and the java compiler is in its final
prepraration phase)
In addition, it was used in several academic papers in the modeling
domain (Models, etc see a small publication list here :
http://www.kermeta.org/documents/articles/ )
and in industrial projects.
Among the key features of the language itself, I can cite the support
of: aspect oriented programming,
lambda expression, notion of model type, design by contract, ...
Would you be interrested in a collaboration with INRIA ?
Since all our code is already in EPL, there is probaly many ways to
collaborate and incorporate the novel ideas we've experimented
and that worth being included in MXF project
Best regards
Didier Vojtisek
INRIA - Research Engineer
|
|
|
| Re: MXF proposal : collaboration [message #132471 is a reply to message #132409] |
Fri, 23 January 2009 10:27  |
| Eclipse User |
|
|
|
Hi Didier,
comments below.
Didier Vojtisek schrieb:
> Hello
>
> We just received the notification of the new MXF (Model eXecution
> Framework) project proposal which sound great.
> (we strongly believe in executable metamodelling applications)
thanks a lot for your feedback. So I'll add INRIA to the list of
interested parties?
> Actually, this project seems closely related to the existing Kermeta
> project (project web page : www.kermeta.org) of the INRIA French
> research institute (www.inria.fr)
> This is an open source project (EPL) that started in 2005 (project forge
> : http://gforge.inria.fr/projects/kermeta/).
> Kermeta provides an operational semantics to MOF (just like MXF plan to
> do) and provides
> an eclipse based workbench (seamlessly uses ecore) (includes editors,
> various views, intrepreter, and the java compiler is in its final
> prepraration phase)
> In addition, it was used in several academic papers in the modeling
> domain (Models, etc see a small publication list here :
> http://www.kermeta.org/documents/articles/ )
> and in industrial projects.
Yes, I know the KerMeta project (actually since we met in Lannion for
the QVT implementors workshop...), but I didn't check the status of the
project for over a year. Is the compiler you're working on targeting any
specific runtime environment?
> Among the key features of the language itself, I can cite the support
> of: aspect oriented programming,
> lambda expression, notion of model type, design by contract, ...
>
> Would you be interrested in a collaboration with INRIA ?
> Since all our code is already in EPL, there is probaly many ways to
> collaborate and incorporate the novel ideas we've experimented
> and that worth being included in MXF project
Sounds great. I'm happy to share any ideas or code.
Some immediate (preliminary) suggestion: we could share the metamodel
for operational semantics and have our graphical and your textual syntax
as notations. As far as I know KerMeta, you also heavily use OCL syntax
for queries and the core of the update part is probably very similar.
Cheers,
Michael
>
> Best regards
> Didier Vojtisek
> INRIA - Research Engineer
|
|
| |
| Re: MXF proposal : collaboration [message #132544 is a reply to message #132518] |
Mon, 26 January 2009 13:47 |
| Eclipse User |
|
|
|
Hi Didier,
thanks for your support. Comments below.
>> [...] Is the compiler you're working on
>> targeting any specific runtime environment?
>
> Yes, the compiler targets Java EMF code. As kermeta seamlessly
> reuse/weave the ecore of the user (ie. in your kermeta code you simply
> add a >> require "myMM.ecore" << in order to reuse an existing ecore
> file, then you can add the behavior you want on top of it.) The
> generated code is partially tackled by ecore genmodel itself (for the
> structural part) so it is fully compatible with EMF based applications
> (including editors)
Ok, did I get that right: you're describing the behaviour in terms of
KerMeta scripts and generate the behaviour directly into corresponding
EMF operations? I'm wondering if there is some specific runtime
library/framework?
>> Sounds great. I'm happy to share any ideas or code.
>> Some immediate (preliminary) suggestion: we could share the metamodel
>> for operational semantics and have our graphical and your textual syntax
> I'll have a look in your operational part to see how compatible they are
> and have more technical question later on.
I think I should do that with KerMeta, too ;)
Basically, we currently support the full OCL query/navigation part + let
statements, single/multi-valued property update, object creation,
explicit iterations over an OCL query, decision nodes, invocation
actions (with optional thread forking), multiple in/out parameters,
atomic action groups. There is no explicit delete operator.
However, from the language constructs, I guess we're missing exceptions
in MActions (which KerMeta supports). Although there might be other
smaller differences as well, I think the main integration challenges are:
(1) Loops: MAction flows can have cycles. Since I guess you don't have a
"goto statement", detecting cycles and mapping them to textual
constructs might be a bit of work...
(2) Threading: Does KerMeta support multiple flows of execution?
MActions support invocations close to a "process fork". To protect
certain regions, MActions provide an "MAtomicGroup" to prevent flow
interruption.
>
> Is it avaible in the source forge project ?
> do you have any presentation/article of it ?
Yes, beside the code at sourceforge e.g. for the ecore files you should
find all information/papers at http://www.metamodels.de. If not, drop me
a line.
> Yes, the core of the syntax (even it it can be improved for some
> details) is quite close to OCL but with some extension (various support
> for metamodel oriented features)
Sounds good, do you use the MDT OCL metamodel/parser or have you build
your own?
Best wishes,
Michael
>
>
> Cheers,
> Didier
> INRIA - Research Engineer
|
|
|
| Re: MXF proposal : collaboration [message #132568 is a reply to message #132544] |
Wed, 28 January 2009 05:31 |
| Eclipse User |
|
|
|
Originally posted by: didier.vojtise_nospam_k.irisa.fr
Hi Michael
Michael Soden a écrit :
> Hi Didier,
>
> thanks for your support. Comments below.
>
>>> [...] Is the compiler you're working on targeting any specific
>>> runtime environment?
>>
>> Yes, the compiler targets Java EMF code. As kermeta seamlessly
>> reuse/weave the ecore of the user (ie. in your kermeta code you simply
>> add a >> require "myMM.ecore" << in order to reuse an existing ecore
>> file, then you can add the behavior you want on top of it.) The
>> generated code is partially tackled by ecore genmodel itself (for the
>> structural part) so it is fully compatible with EMF based applications
>> (including editors)
> Ok, did I get that right: you're describing the behaviour in terms of
> KerMeta scripts and generate the behaviour directly into corresponding
> EMF operations? I'm wondering if there is some specific runtime
> library/framework?
Not, really, everything comes from the kermeta source. and all the
generated code goes into the generated plugin (the generated plugin can
go standalone, the only dependencies are for EMF itself) Some of the
generated code cannot be tackled by ecore genmodel, so it generated by
another complementary generator (for ex: implementation of additional
opreations on primitive type, implementation of lambada expression that
cannot be inlined, etc)
The only part that could be considered as framework, is the definition
of kermeta structures. Since we want to specify the behavior, (for ex,
specifying the behavior of collections or of the kermeta metaclasses
There is no other way, in some places where the defined semantic matches
the one implemented by emf or java, the compiler switch to the more
efficient one (but
>
> Basically, we currently support the full OCL query/navigation part + let
> statements, single/multi-valued property update, object creation,
> explicit iterations over an OCL query, decision nodes, invocation
I wonder how you support that. Is it a translation of OCL into M3Action ?
> actions (with optional thread forking), multiple in/out parameters,
> atomic action groups. There is no explicit delete operator.
same for kermeta
>
> However, from the language constructs, I guess we're missing exceptions
> in MActions (which KerMeta supports). Although there might be other
> smaller differences as well, I think the main integration challenges are:
> (1) Loops: MAction flows can have cycles. Since I guess you don't have a
> "goto statement", detecting cycles and mapping them to textual
> constructs might be a bit of work...
that's probabably, the main discussion. how to connect the core
semantic... Even in UML action semantic (if I remeber well there
somthing about that in the spec) they speak about the need for a surface
language because action flow are very low level concepts (ie. closer
to assembly language than to modern object oriented).
The good point is that in all cases (M3Action, OCL, Kermeta, ...) there
is the Operation.body which is the common attach point to the MOF
struture...
> (2) Threading: Does KerMeta support multiple flows of execution?
> MActions support invocations close to a "process fork". To protect
> certain regions, MActions provide an "MAtomicGroup" to prevent flow
> interruption.
We, don't have "thread" in Kermeta, actually, this is a common request
but we think we have a good reason for not providing it like that (at
least in a language like kermeta): (we have a FAQ page about that point
http://www.kermeta.org/documents/faq/concurrentbehavior)
Since we want to specify behavior, the user must choose his concurrent
paradigm.
Actually, this should be a kind of library that user may use in their
metamodel, without having to mix their own ecore with ecore.ecore (+
action.ecore)
In our experience, unnecessary mix of levels always troubles the user
and leads to strange designs ...
>>
>> Is it avaible in the source forge project ?
>> do you have any presentation/article of it ?
> Yes, beside the code at sourceforge e.g. for the ecore files you should
> find all information/papers at http://www.metamodels.de. If not, drop me
> a line.
>
>> Yes, the core of the syntax (even it it can be improved for some
>> details) is quite close to OCL but with some extension (various
>> support for metamodel oriented features)
> Sounds good, do you use the MDT OCL metamodel/parser or have you build
> your own?
We build our own, for kermeta syntax
for pure OCL syntax, we rely on a old version of EMF OCL parser
(rebundled for compatibility with current versions)
Cheers,
Didier
INRIA - Research Engineer
|
|
|
| Re: MXF proposal : collaboration [message #132634 is a reply to message #132568] |
Wed, 28 January 2009 16:28 |
| Eclipse User |
|
|
|
Hi Didier,
some more answers/discussion points.
>>>> [...] Is the compiler you're working on targeting any specific
>>>> runtime environment?
> [...]
> Not, really, everything comes from the kermeta source. and all the
> generated code goes into the generated plugin (the generated plugin can
> go standalone, the only dependencies are for EMF itself) Some of the
> generated code cannot be tackled by ecore genmodel, so it generated by
> another complementary generator (for ex: implementation of additional
> opreations on primitive type, implementation of lambada expression that
> cannot be inlined, etc)
> The only part that could be considered as framework, is the definition
> of kermeta structures. Since we want to specify the behavior, (for ex,
> specifying the behavior of collections or of the kermeta metaclasses
> There is no other way, in some places where the defined semantic matches
> the one implemented by emf or java, the compiler switch to the more
> efficient one (but
Ok, that's what I meant. I was thinking about all parts that are not
generated and simply delegated to a common runtime library.
>> Basically, we currently support the full OCL query/navigation part +
>> let statements, single/multi-valued property update, object creation,
>> explicit iterations over an OCL query, decision nodes, invocation
> I wonder how you support that. Is it a translation of OCL into M3Action ?
The implementation is reusing the current MDT OCL engine as-is for
parsing/evaluation. Since we use true OCL, expressions are represented
as strings in the MAction.ecore model and pre-parsed before the
interpreter starts. Note that we're working without any code generation.
>> [...] However, from the language constructs, I guess we're missing
>> exceptions in MActions (which KerMeta supports). Although there might
>> be other smaller differences as well, I think the main integration
>> challenges are:
>> (1) Loops: MAction flows can have cycles. Since I guess you don't have
>> a "goto statement", detecting cycles and mapping them to textual
>> constructs might be a bit of work...
> that's probabably, the main discussion. how to connect the core
> semantic... Even in UML action semantic (if I remeber well there
> somthing about that in the spec) they speak about the need for a surface
> language because action flow are very low level concepts (ie. closer to
> assembly language than to modern object oriented).
> The good point is that in all cases (M3Action, OCL, Kermeta, ...) there
> is the Operation.body which is the common attach point to the MOF
> struture...
I had a brief view on the KerMeta language manual and I'm convinced the
common core of basic concepts can be mapped in a straightforward manner.
However, we have to dive into more details and agree on a common set of
concepts. BTW: the lambda expressions look pretty cool. ;)
>> (2) Threading: Does KerMeta support multiple flows of execution?
>> MActions support invocations close to a "process fork". To protect
>> certain regions, MActions provide an "MAtomicGroup" to prevent flow
>> interruption.
> We, don't have "thread" in Kermeta, actually, this is a common request
> but we think we have a good reason for not providing it like that (at
> least in a language like kermeta): (we have a FAQ page about that point
> http://www.kermeta.org/documents/faq/concurrentbehavior)
> Since we want to specify behavior, the user must choose his concurrent
> paradigm.
> Actually, this should be a kind of library that user may use in their
> metamodel, without having to mix their own ecore with ecore.ecore (+
> action.ecore)
> In our experience, unnecessary mix of levels always troubles the user
> and leads to strange designs ...
From my point of view the language should provide a concept for
parallelism. Even though the naming of "thread" might be misleading -
its more a "process" or "agent" - a language designer should have the
choice to either
(1) model parallelism explicitly, i.e. define thread queues, scheduling
policies, monitors, etc. for the new language, or
(2) choose from an existing parallelism model: true concurrency (at
least conceptually), n-processor model, etc.
MActions support (2) and the user can choose between a model of
parallelism. As a direct consequence, the simulation outcome might be
different, e.g. a recorded trace can have object changes of two threads
with exactly the same time-stamp (simulation time instant), or at most n
in the n-processor model (hence n=1 means no parallelism).
> [...]
>>> Yes, the core of the syntax (even it it can be improved for some
>>> details) is quite close to OCL but with some extension (various
>>> support for metamodel oriented features)
>> Sounds good, do you use the MDT OCL metamodel/parser or have you build
>> your own?
>
> We build our own, for kermeta syntax
> for pure OCL syntax, we rely on a old version of EMF OCL parser
> (rebundled for compatibility with current versions)
As said, we're using the MDT OCL. Would be cool if we can reuse the OCL
expression-to-Java part. Maybe other people might be interested in that
part as well...
Best regards,
Michael
>
> Cheers,
> Didier
> INRIA - Research Engineer
|
|
|
| Re: MXF proposal : collaboration [message #132778 is a reply to message #132634] |
Thu, 05 February 2009 04:55 |
| Eclipse User |
|
|
|
Originally posted by: didier.vojtise_nospam_k.irisa.fr
Hi Michael
Ok, I understand your point of view, I completely agree that the
proposal should also provide out of the box support for various commonly
used formalisms and support for runtime (including time and
parallelisms). Then the way it is provided might be discussed.
Maybe a physical meeting would help the discussion to refine the goals
and how to achieve them.
As far as I can see the interested parties are mainly in Europe and
several in France, we can propose to book a meeting room in Paris
(downtown in order to ease the travel and accommodation of people)
would you be interested in such meeting ? If so, which period would suit
you ? (we'll probably need to open a doodle for that)
cheers
Didier
Michael Soden a écrit :
> Hi Didier,
>
> some more answers/discussion points.
>
>>>>> [...] Is the compiler you're working on targeting any specific
>>>>> runtime environment?
>> [...]
>> Not, really, everything comes from the kermeta source. and all the
>> generated code goes into the generated plugin (the generated plugin
>> can go standalone, the only dependencies are for EMF itself) Some of
>> the generated code cannot be tackled by ecore genmodel, so it
>> generated by another complementary generator (for ex: implementation
>> of additional opreations on primitive type, implementation of lambada
>> expression that cannot be inlined, etc)
>> The only part that could be considered as framework, is the definition
>> of kermeta structures. Since we want to specify the behavior, (for ex,
>> specifying the behavior of collections or of the kermeta metaclasses
>> There is no other way, in some places where the defined semantic
>> matches the one implemented by emf or java, the compiler switch to the
>> more efficient one (but
> Ok, that's what I meant. I was thinking about all parts that are not
> generated and simply delegated to a common runtime library.
>
>>> Basically, we currently support the full OCL query/navigation part +
>>> let statements, single/multi-valued property update, object creation,
>>> explicit iterations over an OCL query, decision nodes, invocation
>> I wonder how you support that. Is it a translation of OCL into M3Action ?
> The implementation is reusing the current MDT OCL engine as-is for
> parsing/evaluation. Since we use true OCL, expressions are represented
> as strings in the MAction.ecore model and pre-parsed before the
> interpreter starts. Note that we're working without any code generation.
>
>>> [...] However, from the language constructs, I guess we're missing
>>> exceptions in MActions (which KerMeta supports). Although there might
>>> be other smaller differences as well, I think the main integration
>>> challenges are:
>>> (1) Loops: MAction flows can have cycles. Since I guess you don't
>>> have a "goto statement", detecting cycles and mapping them to textual
>>> constructs might be a bit of work...
>> that's probabably, the main discussion. how to connect the core
>> semantic... Even in UML action semantic (if I remeber well there
>> somthing about that in the spec) they speak about the need for a
>> surface language because action flow are very low level concepts (ie.
>> closer to assembly language than to modern object oriented).
>> The good point is that in all cases (M3Action, OCL, Kermeta, ...)
>> there is the Operation.body which is the common attach point to the
>> MOF struture...
> I had a brief view on the KerMeta language manual and I'm convinced the
> common core of basic concepts can be mapped in a straightforward manner.
> However, we have to dive into more details and agree on a common set of
> concepts. BTW: the lambda expressions look pretty cool. ;)
>
>>> (2) Threading: Does KerMeta support multiple flows of execution?
>>> MActions support invocations close to a "process fork". To protect
>>> certain regions, MActions provide an "MAtomicGroup" to prevent flow
>>> interruption.
>> We, don't have "thread" in Kermeta, actually, this is a common request
>> but we think we have a good reason for not providing it like that (at
>> least in a language like kermeta): (we have a FAQ page about that
>> point http://www.kermeta.org/documents/faq/concurrentbehavior)
>> Since we want to specify behavior, the user must choose his concurrent
>> paradigm.
>> Actually, this should be a kind of library that user may use in their
>> metamodel, without having to mix their own ecore with ecore.ecore (+
>> action.ecore)
>> In our experience, unnecessary mix of levels always troubles the user
>> and leads to strange designs ...
> From my point of view the language should provide a concept for
> parallelism. Even though the naming of "thread" might be misleading -
> its more a "process" or "agent" - a language designer should have the
> choice to either
> (1) model parallelism explicitly, i.e. define thread queues, scheduling
> policies, monitors, etc. for the new language, or
> (2) choose from an existing parallelism model: true concurrency (at
> least conceptually), n-processor model, etc.
>
> MActions support (2) and the user can choose between a model of
> parallelism. As a direct consequence, the simulation outcome might be
> different, e.g. a recorded trace can have object changes of two threads
> with exactly the same time-stamp (simulation time instant), or at most n
> in the n-processor model (hence n=1 means no parallelism).
>
>> [...]
>>>> Yes, the core of the syntax (even it it can be improved for some
>>>> details) is quite close to OCL but with some extension (various
>>>> support for metamodel oriented features)
>>> Sounds good, do you use the MDT OCL metamodel/parser or have you
>>> build your own?
>>
>> We build our own, for kermeta syntax
>> for pure OCL syntax, we rely on a old version of EMF OCL parser
>> (rebundled for compatibility with current versions)
> As said, we're using the MDT OCL. Would be cool if we can reuse the OCL
> expression-to-Java part. Maybe other people might be interested in that
> part as well...
>
> Best regards,
> Michael
>
>
>>
>> Cheers,
>> Didier
>> INRIA - Research Engineer
|
|
|
| Re: MXF proposal : collaboration [message #132790 is a reply to message #132778] |
Thu, 05 February 2009 06:26 |
| Eclipse User |
|
|
|
Hi Didier,
you're right, we have to further discuss these issues. I'm currently
investigating on the additional material provided by Marc and Stéphane
to compile some points for discussion about the architecture.
For the meeting, I've been thinking to start with a kick-off at this
years eclipsecon, where I hope to find more interested people
(especially for the GMF part). I'll post dates when planing is done.
Anyway, a physical meeting after that would be valuable, although our
travel budget this fiscal year is limited (except official eclipse
events). But somehow we should manage that...
Best regards,
Michael
Didier Vojtisek schrieb:
> Hi Michael
>
>
> Ok, I understand your point of view, I completely agree that the
> proposal should also provide out of the box support for various commonly
> used formalisms and support for runtime (including time and
> parallelisms). Then the way it is provided might be discussed.
>
> Maybe a physical meeting would help the discussion to refine the goals
> and how to achieve them.
>
> As far as I can see the interested parties are mainly in Europe and
> several in France, we can propose to book a meeting room in Paris
> (downtown in order to ease the travel and accommodation of people)
> would you be interested in such meeting ? If so, which period would suit
> you ? (we'll probably need to open a doodle for that)
>
> cheers
> Didier
>
|
|
|
| Re: MXF proposal : collaboration [message #132802 is a reply to message #132790] |
Thu, 05 February 2009 07:17 |
| Eclipse User |
|
|
|
Originally posted by: didier.vojtise_nospam_k.irisa.fr
Hi Michael
yes I understand, I also considered going to San Francisco, but when I
saw the price for the travel, this is off budget ... :-(
and I believe that this would probably the case for many european people
If you need help about hte architecture before the meeting I'd be
interested to give you feed back
Best regards
Didier
Michael Soden a écrit :
> Hi Didier,
>
> you're right, we have to further discuss these issues. I'm currently
> investigating on the additional material provided by Marc and Stéphane
> to compile some points for discussion about the architecture.
>
> For the meeting, I've been thinking to start with a kick-off at this
> years eclipsecon, where I hope to find more interested people
> (especially for the GMF part). I'll post dates when planing is done.
>
> Anyway, a physical meeting after that would be valuable, although our
> travel budget this fiscal year is limited (except official eclipse
> events). But somehow we should manage that...
>
> Best regards,
> Michael
>
>
> Didier Vojtisek schrieb:
>> Hi Michael
>>
>>
>> Ok, I understand your point of view, I completely agree that the
>> proposal should also provide out of the box support for various
>> commonly used formalisms and support for runtime (including time and
>> parallelisms). Then the way it is provided might be discussed.
>>
>> Maybe a physical meeting would help the discussion to refine the goals
>> and how to achieve them.
>>
>> As far as I can see the interested parties are mainly in Europe and
>> several in France, we can propose to book a meeting room in Paris
>> (downtown in order to ease the travel and accommodation of people)
>> would you be interested in such meeting ? If so, which period would
>> suit you ? (we'll probably need to open a doodle for that)
>>
>> cheers
>> Didier
>>
|
|
|
| Re: MXF proposal : collaboration [message #620600 is a reply to message #132409] |
Fri, 23 January 2009 10:27 |
| Eclipse User |
|
|
|
Hi Didier,
comments below.
Didier Vojtisek schrieb:
> Hello
>
> We just received the notification of the new MXF (Model eXecution
> Framework) project proposal which sound great.
> (we strongly believe in executable metamodelling applications)
thanks a lot for your feedback. So I'll add INRIA to the list of
interested parties?
> Actually, this project seems closely related to the existing Kermeta
> project (project web page : www.kermeta.org) of the INRIA French
> research institute (www.inria.fr)
> This is an open source project (EPL) that started in 2005 (project forge
> : http://gforge.inria.fr/projects/kermeta/).
> Kermeta provides an operational semantics to MOF (just like MXF plan to
> do) and provides
> an eclipse based workbench (seamlessly uses ecore) (includes editors,
> various views, intrepreter, and the java compiler is in its final
> prepraration phase)
> In addition, it was used in several academic papers in the modeling
> domain (Models, etc see a small publication list here :
> http://www.kermeta.org/documents/articles/ )
> and in industrial projects.
Yes, I know the KerMeta project (actually since we met in Lannion for
the QVT implementors workshop...), but I didn't check the status of the
project for over a year. Is the compiler you're working on targeting any
specific runtime environment?
> Among the key features of the language itself, I can cite the support
> of: aspect oriented programming,
> lambda expression, notion of model type, design by contract, ...
>
> Would you be interrested in a collaboration with INRIA ?
> Since all our code is already in EPL, there is probaly many ways to
> collaborate and incorporate the novel ideas we've experimented
> and that worth being included in MXF project
Sounds great. I'm happy to share any ideas or code.
Some immediate (preliminary) suggestion: we could share the metamodel
for operational semantics and have our graphical and your textual syntax
as notations. As far as I know KerMeta, you also heavily use OCL syntax
for queries and the core of the update part is probably very similar.
Cheers,
Michael
>
> Best regards
> Didier Vojtisek
> INRIA - Research Engineer
|
|
|
| Re: MXF proposal : collaboration [message #620604 is a reply to message #132471] |
Mon, 26 January 2009 12:47 |
| Eclipse User |
|
|
|
Hi Mickael
Michael Soden a écrit :
> thanks a lot for your feedback. So I'll add INRIA to the list of
> interested parties?
Yes, please
that would be a start ;-)
> Yes, I know the KerMeta project (actually since we met in Lannion for
> the QVT implementors workshop...), but I didn't check the status of the
> project for over a year. Is the compiler you're working on targeting any
> specific runtime environment?
Yes, the compiler targets Java EMF code. As kermeta seamlessly
reuse/weave the ecore of the user (ie. in your kermeta code you simply
add a >> require "myMM.ecore" << in order to reuse an existing ecore
file, then you can add the behavior you want on top of it.) The
generated code is partially tackled by ecore genmodel itself (for the
structural part) so it is fully compatible with EMF based applications
(including editors)
> Sounds great. I'm happy to share any ideas or code.
> Some immediate (preliminary) suggestion: we could share the metamodel
> for operational semantics and have our graphical and your textual syntax
I'll have a look in your operational part to see how compatible they are
and have more technical question later on.
Is it avaible in the source forge project ?
do you have any presentation/article of it ?
> as notations. As far as I know KerMeta, you also heavily use OCL syntax
> for queries and the core of the update part is probably very similar.
Yes, the core of the syntax (even it it can be improved for some
details) is quite close to OCL but with some extension (various support
for metamodel oriented features)
Cheers,
Didier
INRIA - Research Engineer
|
|
|
| Re: MXF proposal : collaboration [message #620606 is a reply to message #132518] |
Mon, 26 January 2009 13:47 |
| Eclipse User |
|
|
|
Hi Didier,
thanks for your support. Comments below.
>> [...] Is the compiler you're working on
>> targeting any specific runtime environment?
>
> Yes, the compiler targets Java EMF code. As kermeta seamlessly
> reuse/weave the ecore of the user (ie. in your kermeta code you simply
> add a >> require "myMM.ecore" << in order to reuse an existing ecore
> file, then you can add the behavior you want on top of it.) The
> generated code is partially tackled by ecore genmodel itself (for the
> structural part) so it is fully compatible with EMF based applications
> (including editors)
Ok, did I get that right: you're describing the behaviour in terms of
KerMeta scripts and generate the behaviour directly into corresponding
EMF operations? I'm wondering if there is some specific runtime
library/framework?
>> Sounds great. I'm happy to share any ideas or code.
>> Some immediate (preliminary) suggestion: we could share the metamodel
>> for operational semantics and have our graphical and your textual syntax
> I'll have a look in your operational part to see how compatible they are
> and have more technical question later on.
I think I should do that with KerMeta, too ;)
Basically, we currently support the full OCL query/navigation part + let
statements, single/multi-valued property update, object creation,
explicit iterations over an OCL query, decision nodes, invocation
actions (with optional thread forking), multiple in/out parameters,
atomic action groups. There is no explicit delete operator.
However, from the language constructs, I guess we're missing exceptions
in MActions (which KerMeta supports). Although there might be other
smaller differences as well, I think the main integration challenges are:
(1) Loops: MAction flows can have cycles. Since I guess you don't have a
"goto statement", detecting cycles and mapping them to textual
constructs might be a bit of work...
(2) Threading: Does KerMeta support multiple flows of execution?
MActions support invocations close to a "process fork". To protect
certain regions, MActions provide an "MAtomicGroup" to prevent flow
interruption.
>
> Is it avaible in the source forge project ?
> do you have any presentation/article of it ?
Yes, beside the code at sourceforge e.g. for the ecore files you should
find all information/papers at http://www.metamodels.de If not, drop me
a line.
> Yes, the core of the syntax (even it it can be improved for some
> details) is quite close to OCL but with some extension (various support
> for metamodel oriented features)
Sounds good, do you use the MDT OCL metamodel/parser or have you build
your own?
Best wishes,
Michael
>
>
> Cheers,
> Didier
> INRIA - Research Engineer
|
|
|
| Re: MXF proposal : collaboration [message #620608 is a reply to message #132544] |
Wed, 28 January 2009 05:31 |
| Eclipse User |
|
|
|
Hi Michael
Michael Soden a écrit :
> Hi Didier,
>
> thanks for your support. Comments below.
>
>>> [...] Is the compiler you're working on targeting any specific
>>> runtime environment?
>>
>> Yes, the compiler targets Java EMF code. As kermeta seamlessly
>> reuse/weave the ecore of the user (ie. in your kermeta code you simply
>> add a >> require "myMM.ecore" << in order to reuse an existing ecore
>> file, then you can add the behavior you want on top of it.) The
>> generated code is partially tackled by ecore genmodel itself (for the
>> structural part) so it is fully compatible with EMF based applications
>> (including editors)
> Ok, did I get that right: you're describing the behaviour in terms of
> KerMeta scripts and generate the behaviour directly into corresponding
> EMF operations? I'm wondering if there is some specific runtime
> library/framework?
Not, really, everything comes from the kermeta source. and all the
generated code goes into the generated plugin (the generated plugin can
go standalone, the only dependencies are for EMF itself) Some of the
generated code cannot be tackled by ecore genmodel, so it generated by
another complementary generator (for ex: implementation of additional
opreations on primitive type, implementation of lambada expression that
cannot be inlined, etc)
The only part that could be considered as framework, is the definition
of kermeta structures. Since we want to specify the behavior, (for ex,
specifying the behavior of collections or of the kermeta metaclasses
There is no other way, in some places where the defined semantic matches
the one implemented by emf or java, the compiler switch to the more
efficient one (but
>
> Basically, we currently support the full OCL query/navigation part + let
> statements, single/multi-valued property update, object creation,
> explicit iterations over an OCL query, decision nodes, invocation
I wonder how you support that. Is it a translation of OCL into M3Action ?
> actions (with optional thread forking), multiple in/out parameters,
> atomic action groups. There is no explicit delete operator.
same for kermeta
>
> However, from the language constructs, I guess we're missing exceptions
> in MActions (which KerMeta supports). Although there might be other
> smaller differences as well, I think the main integration challenges are:
> (1) Loops: MAction flows can have cycles. Since I guess you don't have a
> "goto statement", detecting cycles and mapping them to textual
> constructs might be a bit of work...
that's probabably, the main discussion. how to connect the core
semantic... Even in UML action semantic (if I remeber well there
somthing about that in the spec) they speak about the need for a surface
language because action flow are very low level concepts (ie. closer
to assembly language than to modern object oriented).
The good point is that in all cases (M3Action, OCL, Kermeta, ...) there
is the Operation.body which is the common attach point to the MOF
struture...
> (2) Threading: Does KerMeta support multiple flows of execution?
> MActions support invocations close to a "process fork". To protect
> certain regions, MActions provide an "MAtomicGroup" to prevent flow
> interruption.
We, don't have "thread" in Kermeta, actually, this is a common request
but we think we have a good reason for not providing it like that (at
least in a language like kermeta): (we have a FAQ page about that point
http://www.kermeta.org/documents/faq/concurrentbehavior)
Since we want to specify behavior, the user must choose his concurrent
paradigm.
Actually, this should be a kind of library that user may use in their
metamodel, without having to mix their own ecore with ecore.ecore (+
action.ecore)
In our experience, unnecessary mix of levels always troubles the user
and leads to strange designs ...
>>
>> Is it avaible in the source forge project ?
>> do you have any presentation/article of it ?
> Yes, beside the code at sourceforge e.g. for the ecore files you should
> find all information/papers at http://www.metamodels.de If not, drop me
> a line.
>
>> Yes, the core of the syntax (even it it can be improved for some
>> details) is quite close to OCL but with some extension (various
>> support for metamodel oriented features)
> Sounds good, do you use the MDT OCL metamodel/parser or have you build
> your own?
We build our own, for kermeta syntax
for pure OCL syntax, we rely on a old version of EMF OCL parser
(rebundled for compatibility with current versions)
Cheers,
Didier
INRIA - Research Engineer
|
|
|
| Re: MXF proposal : collaboration [message #620613 is a reply to message #132568] |
Wed, 28 January 2009 16:28 |
| Eclipse User |
|
|
|
Hi Didier,
some more answers/discussion points.
>>>> [...] Is the compiler you're working on targeting any specific
>>>> runtime environment?
> [...]
> Not, really, everything comes from the kermeta source. and all the
> generated code goes into the generated plugin (the generated plugin can
> go standalone, the only dependencies are for EMF itself) Some of the
> generated code cannot be tackled by ecore genmodel, so it generated by
> another complementary generator (for ex: implementation of additional
> opreations on primitive type, implementation of lambada expression that
> cannot be inlined, etc)
> The only part that could be considered as framework, is the definition
> of kermeta structures. Since we want to specify the behavior, (for ex,
> specifying the behavior of collections or of the kermeta metaclasses
> There is no other way, in some places where the defined semantic matches
> the one implemented by emf or java, the compiler switch to the more
> efficient one (but
Ok, that's what I meant. I was thinking about all parts that are not
generated and simply delegated to a common runtime library.
>> Basically, we currently support the full OCL query/navigation part +
>> let statements, single/multi-valued property update, object creation,
>> explicit iterations over an OCL query, decision nodes, invocation
> I wonder how you support that. Is it a translation of OCL into M3Action ?
The implementation is reusing the current MDT OCL engine as-is for
parsing/evaluation. Since we use true OCL, expressions are represented
as strings in the MAction.ecore model and pre-parsed before the
interpreter starts. Note that we're working without any code generation.
>> [...] However, from the language constructs, I guess we're missing
>> exceptions in MActions (which KerMeta supports). Although there might
>> be other smaller differences as well, I think the main integration
>> challenges are:
>> (1) Loops: MAction flows can have cycles. Since I guess you don't have
>> a "goto statement", detecting cycles and mapping them to textual
>> constructs might be a bit of work...
> that's probabably, the main discussion. how to connect the core
> semantic... Even in UML action semantic (if I remeber well there
> somthing about that in the spec) they speak about the need for a surface
> language because action flow are very low level concepts (ie. closer to
> assembly language than to modern object oriented).
> The good point is that in all cases (M3Action, OCL, Kermeta, ...) there
> is the Operation.body which is the common attach point to the MOF
> struture...
I had a brief view on the KerMeta language manual and I'm convinced the
common core of basic concepts can be mapped in a straightforward manner.
However, we have to dive into more details and agree on a common set of
concepts. BTW: the lambda expressions look pretty cool. ;)
>> (2) Threading: Does KerMeta support multiple flows of execution?
>> MActions support invocations close to a "process fork". To protect
>> certain regions, MActions provide an "MAtomicGroup" to prevent flow
>> interruption.
> We, don't have "thread" in Kermeta, actually, this is a common request
> but we think we have a good reason for not providing it like that (at
> least in a language like kermeta): (we have a FAQ page about that point
> http://www.kermeta.org/documents/faq/concurrentbehavior)
> Since we want to specify behavior, the user must choose his concurrent
> paradigm.
> Actually, this should be a kind of library that user may use in their
> metamodel, without having to mix their own ecore with ecore.ecore (+
> action.ecore)
> In our experience, unnecessary mix of levels always troubles the user
> and leads to strange designs ...
From my point of view the language should provide a concept for
parallelism. Even though the naming of "thread" might be misleading -
its more a "process" or "agent" - a language designer should have the
choice to either
(1) model parallelism explicitly, i.e. define thread queues, scheduling
policies, monitors, etc. for the new language, or
(2) choose from an existing parallelism model: true concurrency (at
least conceptually), n-processor model, etc.
MActions support (2) and the user can choose between a model of
parallelism. As a direct consequence, the simulation outcome might be
different, e.g. a recorded trace can have object changes of two threads
with exactly the same time-stamp (simulation time instant), or at most n
in the n-processor model (hence n=1 means no parallelism).
> [...]
>>> Yes, the core of the syntax (even it it can be improved for some
>>> details) is quite close to OCL but with some extension (various
>>> support for metamodel oriented features)
>> Sounds good, do you use the MDT OCL metamodel/parser or have you build
>> your own?
>
> We build our own, for kermeta syntax
> for pure OCL syntax, we rely on a old version of EMF OCL parser
> (rebundled for compatibility with current versions)
As said, we're using the MDT OCL. Would be cool if we can reuse the OCL
expression-to-Java part. Maybe other people might be interested in that
part as well...
Best regards,
Michael
>
> Cheers,
> Didier
> INRIA - Research Engineer
|
|
|
| Re: MXF proposal : collaboration [message #620624 is a reply to message #132634] |
Thu, 05 February 2009 04:55 |
| Eclipse User |
|
|
|
Hi Michael
Ok, I understand your point of view, I completely agree that the
proposal should also provide out of the box support for various commonly
used formalisms and support for runtime (including time and
parallelisms). Then the way it is provided might be discussed.
Maybe a physical meeting would help the discussion to refine the goals
and how to achieve them.
As far as I can see the interested parties are mainly in Europe and
several in France, we can propose to book a meeting room in Paris
(downtown in order to ease the travel and accommodation of people)
would you be interested in such meeting ? If so, which period would suit
you ? (we'll probably need to open a doodle for that)
cheers
Didier
Michael Soden a écrit :
> Hi Didier,
>
> some more answers/discussion points.
>
>>>>> [...] Is the compiler you're working on targeting any specific
>>>>> runtime environment?
>> [...]
>> Not, really, everything comes from the kermeta source. and all the
>> generated code goes into the generated plugin (the generated plugin
>> can go standalone, the only dependencies are for EMF itself) Some of
>> the generated code cannot be tackled by ecore genmodel, so it
>> generated by another complementary generator (for ex: implementation
>> of additional opreations on primitive type, implementation of lambada
>> expression that cannot be inlined, etc)
>> The only part that could be considered as framework, is the definition
>> of kermeta structures. Since we want to specify the behavior, (for ex,
>> specifying the behavior of collections or of the kermeta metaclasses
>> There is no other way, in some places where the defined semantic
>> matches the one implemented by emf or java, the compiler switch to the
>> more efficient one (but
> Ok, that's what I meant. I was thinking about all parts that are not
> generated and simply delegated to a common runtime library.
>
>>> Basically, we currently support the full OCL query/navigation part +
>>> let statements, single/multi-valued property update, object creation,
>>> explicit iterations over an OCL query, decision nodes, invocation
>> I wonder how you support that. Is it a translation of OCL into M3Action ?
> The implementation is reusing the current MDT OCL engine as-is for
> parsing/evaluation. Since we use true OCL, expressions are represented
> as strings in the MAction.ecore model and pre-parsed before the
> interpreter starts. Note that we're working without any code generation.
>
>>> [...] However, from the language constructs, I guess we're missing
>>> exceptions in MActions (which KerMeta supports). Although there might
>>> be other smaller differences as well, I think the main integration
>>> challenges are:
>>> (1) Loops: MAction flows can have cycles. Since I guess you don't
>>> have a "goto statement", detecting cycles and mapping them to textual
>>> constructs might be a bit of work...
>> that's probabably, the main discussion. how to connect the core
>> semantic... Even in UML action semantic (if I remeber well there
>> somthing about that in the spec) they speak about the need for a
>> surface language because action flow are very low level concepts (ie.
>> closer to assembly language than to modern object oriented).
>> The good point is that in all cases (M3Action, OCL, Kermeta, ...)
>> there is the Operation.body which is the common attach point to the
>> MOF struture...
> I had a brief view on the KerMeta language manual and I'm convinced the
> common core of basic concepts can be mapped in a straightforward manner.
> However, we have to dive into more details and agree on a common set of
> concepts. BTW: the lambda expressions look pretty cool. ;)
>
>>> (2) Threading: Does KerMeta support multiple flows of execution?
>>> MActions support invocations close to a "process fork". To protect
>>> certain regions, MActions provide an "MAtomicGroup" to prevent flow
>>> interruption.
>> We, don't have "thread" in Kermeta, actually, this is a common request
>> but we think we have a good reason for not providing it like that (at
>> least in a language like kermeta): (we have a FAQ page about that
>> point http://www.kermeta.org/documents/faq/concurrentbehavior)
>> Since we want to specify behavior, the user must choose his concurrent
>> paradigm.
>> Actually, this should be a kind of library that user may use in their
>> metamodel, without having to mix their own ecore with ecore.ecore (+
>> action.ecore)
>> In our experience, unnecessary mix of levels always troubles the user
>> and leads to strange designs ...
> From my point of view the language should provide a concept for
> parallelism. Even though the naming of "thread" might be misleading -
> its more a "process" or "agent" - a language designer should have the
> choice to either
> (1) model parallelism explicitly, i.e. define thread queues, scheduling
> policies, monitors, etc. for the new language, or
> (2) choose from an existing parallelism model: true concurrency (at
> least conceptually), n-processor model, etc.
>
> MActions support (2) and the user can choose between a model of
> parallelism. As a direct consequence, the simulation outcome might be
> different, e.g. a recorded trace can have object changes of two threads
> with exactly the same time-stamp (simulation time instant), or at most n
> in the n-processor model (hence n=1 means no parallelism).
>
>> [...]
>>>> Yes, the core of the syntax (even it it can be improved for some
>>>> details) is quite close to OCL but with some extension (various
>>>> support for metamodel oriented features)
>>> Sounds good, do you use the MDT OCL metamodel/parser or have you
>>> build your own?
>>
>> We build our own, for kermeta syntax
>> for pure OCL syntax, we rely on a old version of EMF OCL parser
>> (rebundled for compatibility with current versions)
> As said, we're using the MDT OCL. Would be cool if we can reuse the OCL
> expression-to-Java part. Maybe other people might be interested in that
> part as well...
>
> Best regards,
> Michael
>
>
>>
>> Cheers,
>> Didier
>> INRIA - Research Engineer
|
|
|
| Re: MXF proposal : collaboration [message #620625 is a reply to message #132778] |
Thu, 05 February 2009 06:26 |
| Eclipse User |
|
|
|
Hi Didier,
you're right, we have to further discuss these issues. I'm currently
investigating on the additional material provided by Marc and Stéphane
to compile some points for discussion about the architecture.
For the meeting, I've been thinking to start with a kick-off at this
years eclipsecon, where I hope to find more interested people
(especially for the GMF part). I'll post dates when planing is done.
Anyway, a physical meeting after that would be valuable, although our
travel budget this fiscal year is limited (except official eclipse
events). But somehow we should manage that...
Best regards,
Michael
Didier Vojtisek schrieb:
> Hi Michael
>
>
> Ok, I understand your point of view, I completely agree that the
> proposal should also provide out of the box support for various commonly
> used formalisms and support for runtime (including time and
> parallelisms). Then the way it is provided might be discussed.
>
> Maybe a physical meeting would help the discussion to refine the goals
> and how to achieve them.
>
> As far as I can see the interested parties are mainly in Europe and
> several in France, we can propose to book a meeting room in Paris
> (downtown in order to ease the travel and accommodation of people)
> would you be interested in such meeting ? If so, which period would suit
> you ? (we'll probably need to open a doodle for that)
>
> cheers
> Didier
>
|
|
|
| Re: MXF proposal : collaboration [message #620626 is a reply to message #132790] |
Thu, 05 February 2009 07:17 |
| Eclipse User |
|
|
|
Hi Michael
yes I understand, I also considered going to San Francisco, but when I
saw the price for the travel, this is off budget ... :-(
and I believe that this would probably the case for many european people
If you need help about hte architecture before the meeting I'd be
interested to give you feed back
Best regards
Didier
Michael Soden a écrit :
> Hi Didier,
>
> you're right, we have to further discuss these issues. I'm currently
> investigating on the additional material provided by Marc and Stéphane
> to compile some points for discussion about the architecture.
>
> For the meeting, I've been thinking to start with a kick-off at this
> years eclipsecon, where I hope to find more interested people
> (especially for the GMF part). I'll post dates when planing is done.
>
> Anyway, a physical meeting after that would be valuable, although our
> travel budget this fiscal year is limited (except official eclipse
> events). But somehow we should manage that...
>
> Best regards,
> Michael
>
>
> Didier Vojtisek schrieb:
>> Hi Michael
>>
>>
>> Ok, I understand your point of view, I completely agree that the
>> proposal should also provide out of the box support for various
>> commonly used formalisms and support for runtime (including time and
>> parallelisms). Then the way it is provided might be discussed.
>>
>> Maybe a physical meeting would help the discussion to refine the goals
>> and how to achieve them.
>>
>> As far as I can see the interested parties are mainly in Europe and
>> several in France, we can propose to book a meeting room in Paris
>> (downtown in order to ease the travel and accommodation of people)
>> would you be interested in such meeting ? If so, which period would
>> suit you ? (we'll probably need to open a doodle for that)
>>
>> cheers
>> Didier
>>
|
|
|
Goto Forum:
Current Time: Sat May 10 18:42:19 EDT 2025
Powered by FUDForum. Page generated in 0.04316 seconds |
Home