| Re: [gemoc-dev] File modifications in GEMOC engines |
|
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----- 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.
-
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.
-
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. 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? Oh, and what is the purpose of ModelExecutionContext copying the model into the execution workspace if that model file is never actually used? > 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? 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=""> > > _______________________________________________ > gemoc-dev mailing list > To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit >
https://emea01.safelinks.protection.outlook.com/?url=""> > .eclipse.org%2Fmailman%2Flistinfo%2Fgemoc-dev&data=""> > en.zschaler%40kcl.ac.uk%7C1dd37f7bce0b4084e2da08d5e5939161%7C8370cf141 > 6f34c16b83c724071654356%7C0&sdata=ifrk5teeac%2FMq%2F3GF1gX9bRsjjfP > j8O2xnoLto6KHjw%3D&reserved=0 _______________________________________________ gemoc-dev mailing list To change your delivery options, retrieve your password, or unsubscribe from this list, visit |