[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [gemoc-dev] File modifications in GEMOC engines
|
Le lundi 09 juillet 2018 à 13:03 +0000, Zschaler, Steffen a écrit :
> Thanks. Please find responses in-line below...
>
> Many thanks,
>
> Steffen
>
> Dr. rer. nat. Steffen Zschaler AHEA
> Senior Lecturer
>
> King's College London
> Department of Informatics
>
> Email szschaler@xxxxxxx
> Phone +44 (020) 7848 1513
> WWW http://www.steffen-zschaler.de/
>
>
> -----Original Message-----
> From: gemoc-dev-bounces@xxxxxxxxxxx [mailto:gemoc-dev-bounces@eclipse
> .org] On Behalf Of Bousse, Erwan Gwendal
> Sent: 09 July 2018 13:00
> To: gemoc-dev@xxxxxxxxxxx
> Subject: Re: [gemoc-dev] File modifications in GEMOC engines
>
> Hi Steffen!
>
>
> To answer your questions, we would need to know more about what you
> are trying to achieve, and what kinds of semantics your engine will
> work with. Is your source code publicly available somewhere, by any
> chance?
>
> >> Unfortunately, not at the moment.
>
> Or would you have time to describe what you do in more detail?
>
> >> Happy to, see below.
>
> For instance:
> - do you define the dynamic state of your models directly inside your
> Ecore abstract syntax file, or do you define it separately?
>
> >> For the moment, it's integrated. I will look at separating this
> out again, but this will happen outside of the GEMOC engine and I
> think I know how to do that part.
OK
>
> - if it is defined separately, how?
> - what kind of transformation language is used to define your
> semantics? does it also take care of defining the dynamic state? how
> does it load the model it executes?
>
> >> I use Henshin (i.e, graph-transformation systems) to describe
> operational semantics. I have built an execution engine extending
> AbstractSequentialExecutionEngine (this may have to change at some
> point as there actually is a fair amount of "parallelism" in my
> languages, but works for me for now), which tries to use standard
> bits as much as possible, taking inspiration from
> PlainK3ExecutionEngine code. I had to be a bit radical in some
> places; in particular
> - I removed the language definition bits from
> ModelExecutionContext, replacing them with hard-coding to the
> DefaultModelLoader, as I couldn’t figure out how to tie my way of
> expressing language semantics into Melange and, thus, into the
> standard language definition stuff.
Yes you should not try using Melange, as it only supports a couple of
model transformation languages (K3 and xMOF).
> - I had to be a bit creative when calling
> beforeStep/afterStep as there aren’t actually any meaningful
> operations in my abstract syntax (it’s all in the Henshin rules). I’m
> pretending to GEMOC that I always call an operation called `
> invokeRule` on the root meta-class of the abstract syntax.
Wouldn't it be possible to tell GEMOC that the called operation is the
rule itself, with its real name?
> - I had to build my own launcher and launch configuration. I
> currently don’t support the addon stuff, because it seemed tangential
> to what I am trying to get done and wasn’t built in a particularly
> easily reusable fashion.
Yes one of our mid-term goal is to provide a fully generic Launcher
that can work accross engines. In the meantime, the best you can do is
to mimic existing launcher we have.
>
> Also, a few comments below:
>
> Le lundi 09 juillet 2018 à 10:38 +0000, Zschaler, Steffen a écrit :
> > Hi,
> >
> > I’m working on a new execution engine for the GEMOC studio. It
> seems
> > to be working well, though I have had to be a bit rough in
> integrating
> > it in some places. One problem I have, at the moment, however, is
> > figuring out which resource to modify and whose responsibility it
> is
> > to save that resource and when. As a result, I get some strange
> > effects:
> >
> > 1. I have chosen to use executionContext.getResourceModel()
> as
> > the resource to modify, but have found out that that is not the
> > resource in the new execution workspace, but rather the original
> model
> > file. It does seem to be, however, the resource for which the
> > corresponding Sirius diagram is opened. So my first question is:
> > Should I open that resource or should I use
> > executionWorkSpace.getModelPath to find and load the copied
> resource?
>
> The resource to modify should be the original one. GEMOC Studio
> automatically disables saving on the loaded resource to make sure
> that all changes made for the execution are transient/temporary. It
> should be the same resource that is loaded by Sirius, if I am
> correct. You should never have to load the model yourself, the model
> loader should take care of it once and then you programatically give
> the model content to the interpreter.
>
> >>So, you’re saying I’m loading the correct resource.
> getResourceModel gives me the resource that the model loader has
> loaded, so that sounds good. But, why then does the Sirius diagram
> not update? Is it possible that I am using GEMOC wrong in some way?
Yes, your launcher retrieves a URI that should be given to the model
loader, which initializes the execution context with the obtained
resource. This unique resource is used for everything from then on.
Hence, I am not sure why the Sirius Animation is not working.
- Have you correctly defined a graphical concrete syntax that is able
to reflect the current execution state of your model?
- Do you give the aird file of the model to your launch configuration,
when executing a model?
- Do you start the execution in debug mode?
- Does your launcher extends AbstractSequentialGemocLauncher?
> Oh, and what is the purpose of ModelExecutionContext copying the
> model into the execution workspace if that model file is never
> actually used?
It was used at some point to store an archive of the model next to the
corresponding execution trace, but at the moment I believe it's not
being used anymore. We plan to probably remove this feature, or at
least make it smarter (eg. only copy the model when this is useful).
>
> > 2. When I have run my program, I see the results in the Model
> > Explorer. However, these results don’t seem to have been saved to
> the
> > actual resource on disk: the Sirius diagram has not been updated
> and
> > if I open the model file directly in its tree editor, I see only
> the
> > original contents. So, my second question is: should I expect the
> > resource to be saved automatically or is my execution engine
> expected
> > to do so? If so, when am I expected to do any saves?
>
> As said above, nothing should be saved on disk, except maybe an
> archive of the model and an execution trace (but neither of these are
> relevant at runtime). The Sirius representation should be
> automatically updated even if the file is never changed, thanks to
> how sirius is Integrated to GEMOC. You should never have to save the
> file, nor to take care of anything in particular to have Sirius
> animation working.
>
> >> Hmm, strange. Might I have accidentally removed some feature in my
> code, then?
That's a possibility, although if you extend
AbstractSequentialGemocLauncher and AbstractSequentialEngine we should
be rather good. I'll keep thinking.
>
>
> Hope it helps! Good luck and welcome in GEMOC development :)
>
> Regards,
> Erwan
>
>
> >
> > Any suggestions would be most welcome…
> >
> > Many thanks,
> >
> > Steffen
> >
> >
> > Dr. rer. nat. Steffen Zschaler AHEA
> > Senior Lecturer
> >
> > King's College London
> > Department of Informatics
> >
> > Email szschaler@xxxxxxx
> > Phone +44 (020) 7848 1513
> > WWW https://emea01.safelinks.protection.outlook.com/?url=http%3A%
> 2F%2Fwww.steffen-
> zschaler.de%2F&data=01%7C01%7Csteffen.zschaler%40kcl.ac.uk%7C1dd3
> 7f7bce0b4084e2da08d5e5939161%7C8370cf1416f34c16b83c724071654356%7C0&a
> mp;sdata=FfQrnKIDH3lXKhvsYpvMvSdg3xQJRxiuw8o3bdkc7Tg%3D&reserved=
> 0
> >
> > _______________________________________________
> > gemoc-dev mailing list
> > gemoc-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or
> > unsubscribe from this list, visit
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> dev
> > .eclipse.org%2Fmailman%2Flistinfo%2Fgemoc-
> dev&data=01%7C01%7Csteff
> >
> en.zschaler%40kcl.ac.uk%7C1dd37f7bce0b4084e2da08d5e5939161%7C8370cf14
> 1
> >
> 6f34c16b83c724071654356%7C0&sdata=ifrk5teeac%2FMq%2F3GF1gX9bRsjjf
> P
> > j8O2xnoLto6KHjw%3D&reserved=0
> _______________________________________________
> gemoc-dev mailing list
> gemoc-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fde
> v.eclipse.org%2Fmailman%2Flistinfo%2Fgemoc-
> dev&data=01%7C01%7Csteffen.zschaler%40kcl.ac.uk%7C1dd37f7bce0b408
> 4e2da08d5e5939161%7C8370cf1416f34c16b83c724071654356%7C0&sdata=if
> rk5teeac%2FMq%2F3GF1gX9bRsjjfPj8O2xnoLto6KHjw%3D&reserved=0
> _______________________________________________
> gemoc-dev mailing list
> gemoc-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/gemoc-dev
