Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [gemoc-dev] File modifications in GEMOC engines

Hi

did your engine and semantic correctly use EMFTransaction (ie. RecordingCommand)?

This is required in order to trigger the emf notifiactions when the resource content changes. Sirius editor/animator is listening to these notifications to perform the diagram refresh.

in the AbstractSequentialExecutionEngine this is done via the RecordingCommand stuff in beforeExecutionStep()  so depending on how you implement it make sure to either call it or mimic its behavior.


in other engines such as the concurrent engine, this is done differently since the calls as supposed atomic (see https://github.com/gemoc/concurrency/blob/253195ae60d875bd9c06e56e10da88d286e501f0/ccsljava_execution/ccsljava_engine/plugins/org.eclipse.gemoc.execution.concurrent.ccsljavaengine.extensions.timesquare/src/main/java/org/eclipse/gemoc/execution/concurrent/ccsljavaengine/extensions/timesquare/moc/impl/CcslSolver.java#L604)

best regards
Didier

Le 10/07/2018 à 19:49, Zschaler, Steffen a écrit :
Thanks. I will get the debug mode working and see what happens then...

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: 10 July 2018 12:43
To: gemoc-dev@xxxxxxxxxxx
Subject: Re: [gemoc-dev] File modifications in GEMOC engines

Hi!


Animation is only enabled when executing in debug mode, as we consider animation to be part of the debugging activity.

More precisely, despite the fact that the launch configuration does always give the possibility to point to the aird of the model to execute, this piece of information is actually only used in debug mode. We should probably add a tooltip to explain this.

In other words, try executing in debug mode, and let's see if that solves anything :). Don't worry if you haven't taken care of debugging support yet, the execution should still work I believe.

Regarding the debug layer, it's basically a way to tell GEMOC that part of the concrete syntax should only be used when executing, and not when designing. But if I remember correctly, if you put both your static and dynamic graphical elements in one unique odesign layer, I believe animation should work regardless of this debug layer.


Regards,
Erwan

Le mardi 10 juillet 2018 à 07:09 +0000, Zschaler, Steffen a écrit :
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.Launche
r 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   https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.steffen-zschaler.de%2F&data=01%7C01%7Csteffen.zschaler%40kcl.ac.uk%7C9a7bde1886064036085408d5e65a4f26%7C8370cf1416f34c16b83c724071654356%7C0&sdata=wpJmDhU0sU168P17UmDWvnqaeCFnUnSwMLIfzp0uHUI%3D&reserved=0
-----Original Message-----
From: gemoc-dev-bounces@xxxxxxxxxxx [mailto:gemoc-dev-bounces@eclipse
.org] 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=http%3A%
2F%2Fwww.steffen-
zschaler.de%2F&data=01%7C01%7Csteffen.zschaler%40kcl.ac.uk%7C5c86
94efe527414ff65e08d5e5ac904b%7C8370cf1416f34c16b83c724071654356%7C0&a
mp;sdata=ZwICrUzNsq%2FtMbo9f5w4pD7jTUhYoxQMrDyqFIQylrE%3D&reserve
d=0

-----Original Message-----
From: gemoc-dev-bounces@xxxxxxxxxxx [mailto:gemoc-dev-bounces@eclip
se
.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%3
A%
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%2F
de
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://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%7C5c8694efe527414ff65e08d5e5ac904b%7C8370cf14
1
6f34c16b83c724071654356%7C0&sdata=maqpSq4U16lA7nOl7l43b9cBPBTfnc0
O
gjj%2FXErfRS0%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%7C5c8694efe527414
ff65e08d5e5ac904b%7C8370cf1416f34c16b83c724071654356%7C0&sdata=ma
qpSq4U16lA7nOl7l43b9cBPBTfnc0Ogjj%2FXErfRS0%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%2Fdev
.eclipse.org%2Fmailman%2Flistinfo%2Fgemoc-dev&data=01%7C01%7Csteff
en.zschaler%40kcl.ac.uk%7C9a7bde1886064036085408d5e65a4f26%7C8370cf141
6f34c16b83c724071654356%7C0&sdata=8GgsBZP4%2Fc7DTB%2BMGmuPqOKdk2zw
uY%2BuReqakoFzGQU%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%2Fdev.eclipse.org%2Fmailman%2Flistinfo%2Fgemoc-dev&data=01%7C01%7Csteffen.zschaler%40kcl.ac.uk%7C9a7bde1886064036085408d5e65a4f26%7C8370cf1416f34c16b83c724071654356%7C0&sdata=8GgsBZP4%2Fc7DTB%2BMGmuPqOKdk2zwuY%2BuReqakoFzGQU%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

--
Didier Vojtisek
SED Rennes - DiverSE Team
Univ Rennes, Inria, CNRS, IRISA
Campus de beaulieu
35042 Rennes
02 99 84 75 07



Back to the top