[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [gemoc-dev] File modifications in GEMOC engines
|
Thanks, Didier. Yes, my engine does correctly use recording commands. I had a good call with Erwan yesterday and we managed to find out what the problem was. It was, in fact, nothing to do with my engine, but a problem in my odesign, which did not specify the required service for identifying the layers to update on animation. Once I fixed that, things worked quite nicely :-)
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 Didier Vojtisek
Sent: 17 July 2018 08:42
To: gemoc-dev@xxxxxxxxxxx
Subject: 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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgemoc%2Fconcurrency%2Fblob%2F253195ae60d875bd9c06e56e10da88d286e501f0%2Fccsljava_execution%2Fccsljava_engine%2Fplugins%2Forg.eclipse.gemoc.execution.concurrent.ccsljavaengine.extensions.timesquare%2Fsrc%2Fmain%2Fjava%2Forg%2Feclipse%2Fgemoc%2Fexecution%2Fconcurrent%2Fccsljavaengine%2Fextensions%2Ftimesquare%2Fmoc%2Fimpl%2FCcslSolver.java%23L604&data=01%7C01%7Csteffen.zschaler%40kcl.ac.uk%7Cb27ed5edb5b9472558c608d5ebb8dde6%7C8370cf1416f34c16b83c724071654356%7C0&sdata=QbmyhmQoJ5ZFGVjr%2FEBW9xqZPiPQTaBQpG%2Fxhng1Y0I%3D&reserved=0)
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 https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.steffen-zschaler.de%2F&data=01%7C01%7Csteffen.zschaler%40kcl.ac.uk%7Cb27ed5edb5b9472558c608d5ebb8dde6%7C8370cf1416f34c16b83c724071654356%7C0&sdata=nxLCpcLJSbuy8AosGHcMJXMyPLDSHUy0WPjeLX1Zf4I%3D&reserved=0
>
>
> -----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%2Fde
>> v
>> .eclipse.org%2Fmailman%2Flistinfo%2Fgemoc-dev&data=01%7C01%7Cstef
>> f
>> en.zschaler%40kcl.ac.uk%7C9a7bde1886064036085408d5e65a4f26%7C8370cf14
>> 1
>> 6f34c16b83c724071654356%7C0&sdata=8GgsBZP4%2Fc7DTB%2BMGmuPqOKdk2z
>> w
>> 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%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%7Csteff
> en.zschaler%40kcl.ac.uk%7Cb27ed5edb5b9472558c608d5ebb8dde6%7C8370cf141
> 6f34c16b83c724071654356%7C0&sdata=M3%2F1XH4c6w2SED7luaAt67DUK%2BrN
> 3CtM%2FDR%2Btyn1LZs%3D&reserved=0
--
Didier Vojtisek
SED Rennes - DiverSE Team
Univ Rennes, Inria, CNRS, IRISA
Campus de beaulieu
35042 Rennes
02 99 84 75 07
_______________________________________________
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%7Cb27ed5edb5b9472558c608d5ebb8dde6%7C8370cf1416f34c16b83c724071654356%7C0&sdata=M3%2F1XH4c6w2SED7luaAt67DUK%2BrN3CtM%2FDR%2Btyn1LZs%3D&reserved=0
