[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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 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 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://dev.eclipse.org/mailman/listinfo/gemoc-dev
