Re: [gemoc-dev] File modifications in GEMOC engines

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]

Re: [gemoc-dev] File modifications in GEMOC engines

From: "Zschaler, Steffen" <steffen.zschaler@xxxxxxxxx>
Date: Tue, 10 Jul 2018 07:09:06 +0000
Accept-language: en-GB, en-US
Delivered-to: gemoc-dev@xxxxxxxxxxx
List-archive: <https://dev.eclipse.org/mailman/private/gemoc-dev>
List-help: <mailto:gemoc-dev-request@eclipse.org?subject=help>
List-subscribe: <https://dev.eclipse.org/mailman/listinfo/gemoc-dev>, <mailto:gemoc-dev-request@eclipse.org?subject=subscribe>
List-unsubscribe: <https://dev.eclipse.org/mailman/options/gemoc-dev>, <mailto:gemoc-dev-request@eclipse.org?subject=unsubscribe>
Thread-index: AdQXcOLMkSJXh1mIQLqDsWgkXkobp///9YqA///SQqCAAF+8gP/+09mg
Thread-topic: [gemoc-dev] File modifications in GEMOC engines

Hi,

Many thanks for this detailed response. It seems like I'm on the right track.

I have been thinking that I may be missing something in my odesign file for the example language rather than in the engine proper and your comments below suggest that this may be a direction worth exploring further. My current odesign should be able to reflect arbitrary dynamic states of the example, but it may be missing stuff that GEMOC expects to find.

My engine extends AbstractSequentialExecutionEngine. My launcher extends AbstractSequentialGemocLauncher, and the code for the launcher is effectively copied/adapted from org.eclipse.gemoc.execution.sequential.javaengine.ui.launcher.Launcher except that I provide my own subclass of ModelExecutionContext that mocks up a LanguageDefinitionExtension.

I don’t explicitly run my model in “debug” mode (i.e., I use the “Run” rather than the “Debug” button to start it), but I provide an aird file as part of the run configuration and that is opened by the model loader. I haven’t yet implemented full debug support (it seems to need me to fill in a few more helper methods at least and fiddle with some more of the LanguageDefinitionExtension stuff).

The launcher warns that there is no debug layer in the odesign (“No debug service defined in the odesign for the debug model id”). I haven’t yet provided one, because I wouldn’t know what to provide in there (all the dynamic state is already reflected in the default layer for my example). Could this cause problems for the animation?

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@xxxxxxxxxxx] On Behalf Of Bousse, Erwan Gwendal
Sent: 09 July 2018 15:59
To: gemoc-dev@xxxxxxxxxxx
Subject: 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 https://emea01.safelinks.protection.outlook.com/?url="">

> -----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.

> - 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