eclipse / gemoc-studio-modeldebugging

gemoc-studio-modeldebugging

---

This repository is part of a serie of repositories related to GEMOC Studio :

• https://github.com/eclipse/gemoc-studio
• https://github.com/eclipse/gemoc-studio-modeldebugging
• https://github.com/eclipse/gemoc-studio-execution-ale
• https://github.com/eclipse/gemoc-studio-execution-java
• https://github.com/eclipse/gemoc-studio-execution-moccml
• https://github.com/eclipse/gemoc-studio-moccml
• https://github.com/eclipse/gemoc-studio-commons

---

ModelDebugging

Runtime and tools to bring execution, debug and simulation in your domain specific tooling built with Sirius and/or Eclipse Modeling Framework.

To have a better understanding of the features and services offered by this framework, you can read the following post (Breathe life into your designer).

The repository includes several components:

• simulationmodelanimation The plugins required to animate models with Sirius
• framework contains the components used to implement execution engines with model debugging support. The framework is two folds:
• xdsml_framework The plugins for the language workbench (ie. plugins that provides support for designing xdsml languages using a given engine).
• execution_framework The plugins for the modeling workbench (ie. the engine runtime for executing models).
• trace The plugins dedicated to execution traces. It offers two traces implementations that cans be used by the framework:
• a simple generic trace metamodel
• an efficient trace metamodel powered by a generative approach. This trace enables all omniscient debugging capabilities of the framework and offers a multidimentional timeline.

This project is included within the GEMOC. This project offers an Eclipse package (GEMOC Studio) with all these components preinstalled. It also provides additionnal engines (concurrent engine, coordination of concurrent engines), documentation and tutorials.

This project is still in incubation and need more work to reach industrial grade. If you need some help to get started with this project or have any questions about it feel free to contact Cédric Brun.

Development

• Continuous integration on Eclipse CI
• Instructions for building

gemoc-studio-modeldebugging's Issues

Add a self variable in the Variable view

If we consider the usual Variable view when debugging Java code, its content changes according to the selected element in the stack (Debug view)
Most notably, it has a this variable.

In our case, we could also have an equivalent concept and have a self variable. Its content would be the target of the selected element in the stack.

Note1: in the case of the concurrent engine. As a LogicalStep is composed of several calls, the self variable would be an array.

Note2: mixing RTD and fixed data in the same view can be handled by improving the UI. for example fixed data could use an italic font and RTD could use an icon overlay

Breakpoints do not appear until the next Sirius representation refresh

From SiriusLab/ModelDebugging#4 and probably similar to #56

When adding a breakpoint to a model element using Sirius command during a model execution, the decoration does not appear until the next refresh of the representation.

However, the Breakpoints view is correctly updated

[Concurrency] Task: Remove concurrent debugger

(copied from gemoc/gemoc-studio-old#46)

Currently, we have two separate debuggers:

• sequential: org.gemoc.execution.sequential.javaengine.ui.debug.GenericSequentialModelDebugger
• concurrent: org.gemoc.execution.concurrent.ccsljavaengine.ui.debug.GemocModelDebugger

However, not only a lot of code is identical between both, but the concurrent debugger does very little concurrency-specific things (even less since some of these things are currently broken).

After discussion, we decided to remove the concurrent debugger and to only provide sequential debugging for now, even in the concurrent case. This means that the sequential debugger msut be adapted to be handle as well as it can (ie. not very well) concurrency, as written here: #32

Sirius animator view does not refresh the "current instruction" when clicking in the stack view

The "current instruction" service is supposed to change according to the selected element in the stack view (see AbstractGemocDebuggerServices.java and AbstractDSLDebuggerServices.java)

This is particularly visible in language having both xtext and sirius concrete syntaxes (such as K3FSM official example) since clicking in the stack correctly set the line in the xtext editor but does not change the color in sirius. (Not: The color does changes but only when stepping and is thus mostly incorrect)

Step to reproduce:

• install K3FSM example
• debug down to "transition.fire()" and click in the stack view

(note: "current instruction" must not be confused with "hasbeenanimated" which corresponds to the latest element called)

Revert patch introduced to fix Sirius permission issue when running 2 models at the same time

A patch was introduced in model debugging in order to fix a permission issue when two models conforming the same language are executed at same time

More details: SiriusLab/ModelDebugging#5

It seems that Sirius has included this patch so we should now remove the extra code.

Project wizard template text field with button not udated when filled as text

When using the Gemoc project wizard, in the template part, we use AbstractStringWithButtonOption
to set the ecore file or k3 project.

It works correctly if we use the button, but if we set the text directly in the text field, then the data is not taken into account.
(see https://github.com/eclipse/gemoc-studio-modeldebugging/tree/master/javaAbstractStringWithButtonOption_execution/java_xdsml/plugins/org.eclipse.gemoc.execution.sequential.javaxdsml.ide.ui/src/org/eclipse/gemoc/execution/sequential/javaxdsml/ide/ui/templates)

step to reproduce:

• get some ecore project (for example, import an official sample)
• File > new > create GEMOC Sequential xDSML project
• next, select one of the templates,
• directly set your ecore file in the text field (not using the browse button)

It will generate a project without the ecore file set (as if the user hasn't put any information)

Popup "Create DSA Project for language" does not add the created project to the dependencies

on a GEMOC Sequential Project, right click; "Create DSA Project for language"

This correctly calls K3 wizard, this correctly adds the created aspects (from the xtend file) to the .dsl file, but does not add the created project to the project.

In the launch configuration, this end up with "cannot find method with @main annotation" when trying to use the language even if the method exist and the aspects are correctly referenced in the .dsl file.

Generic trace should report user readable error in case of trouble in the code or in the RTD

in connection with #83, when there are errors due to the use of unimplemented primitive type (EDouble but also many other from ecore or even other defined by the user himself)

There is no error reported in a readable way, we only get NullPointer in cryptic placed without indication about the element that failed to be created or serialized

Similarly crypti error may be raised if some RTD does not correctly defines the @aspect annotation in the ecore. It may raise IllegalArgumentException("The 'no null' constraint is violated") for example. Again a better message would be appreciated in order to help the language designer.

I suggest the use of the MessagingSystem as a logger that would report issues in the error log when run in eclipse workbench or on stdio when run in standalone. or use Platform.getLog(Platform.getBundle(PLUGIN_ID)).log(new Status(Status.WARNING, PLUGIN_ID,

Popup "Create Sirius Editor for language" fails

The popup action "Create Sirius Editor Project for language" fails

Step to reproduce:
on a language project, right click on the project then > GEMOC Language > Create Sirius Editor project for language

This action fails with the following error

wizard with id=org.eclipse.sirius.ui.specificationproject.wizard not found

The target Sirius wizard ID and/or API must have changed ...

Melange file in src folder may lead to corrupt manifest and incorrect deployment

The fact that currently the melange file is contained by a java source folder has several side effects.

1/ the content of src folder is duplicated in the target folder (usually bin folder) thus the gemoc builder that updates the plugin.xml and manifest is launched 2 times

Launching 2 times the builder can have 2 effects,

• the plugin.xml may randomly point to the src or bin version (which is a pain when managing the file in git)
• the manifest writer seems to not be thread safe and lead to corrupt manifest file (see bug such as diverse-project/melange#105)

2/ when deploying the plugin the path to the melange file is not stable, src folder is not supposed to exist in the resulting jar, bin folder doesn't exist as its content is placed at the root of the jar/zip. Thus the path in the plugin.xml is wrong when the plugin is deployed (the path is accidentally correct when using 2 eclipses). It would be safer to put the melange file in a dedicated folder (such as model) and make sure this folder is declared in the bin.includes entry of build.properties file. (ie. similarly to the .ecore, .genmodel, etc)

Cannot run model contained in a project with white spaces in the name

The sequential java engine crashes when trying to initialize the context if the model to execute is contained in a project with a white space in the name.

Step to reproduce the issue:

• get the K3FSM language in the first language workbench
• in the modeling workbench, get the example model, create a new project with a white space( "test test" for example), copy the model in it, close the origin project, create some Sirius representation, create a launch conf and start the execution

It will fail with an exception similar to:

org.eclipse.gemoc.executionframework.engine.commons.EngineContextException: Cannot initialize the execution context, see inner exception.
	at org.eclipse.gemoc.executionframework.engine.commons.AbstractModelExecutionContext.<init>(AbstractModelExecutionContext.java:62)
	at org.eclipse.gemoc.execution.sequential.javaengine.SequentialModelExecutionContext.<init>(SequentialModelExecutionContext.java:27)
	at org.eclipse.gemoc.execution.sequential.javaengine.ui.launcher.Launcher.createExecutionEngine(Launcher.java:38)
	at org.eclipse.gemoc.execution.sequential.javaengine.ui.launcher.Launcher.createExecutionEngine(Launcher.java:1)
	at org.eclipse.gemoc.executionframework.engine.ui.launcher.AbstractSequentialGemocLauncher.launch(AbstractSequentialGemocLauncher.java:108)
	at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:859)
	at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:717)
	at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:1039)
	at org.eclipse.debug.internal.ui.DebugUIPlugin$8.run(DebugUIPlugin.java:1256)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:60)
Caused by: org.eclipse.core.internal.resources.ResourceException: Resource '/test%20test' does not exist.
	at org.eclipse.core.internal.resources.Resource.checkExists(Resource.java:327)
	at org.eclipse.core.internal.resources.Resource.checkAccessible(Resource.java:201)
	at org.eclipse.core.internal.resources.Project.checkAccessible(Project.java:142)
	at org.eclipse.core.internal.resources.Folder.assertCreateRequirements(Folder.java:33)
	at org.eclipse.core.internal.resources.Folder.create(Folder.java:93)
	at org.eclipse.core.internal.resources.Folder.create(Folder.java:121)
	at org.eclipse.gemoc.executionframework.engine.core.ExecutionWorkspace.createFolder(ExecutionWorkspace.java:84)
	at org.eclipse.gemoc.executionframework.engine.core.ExecutionWorkspace.createExecutionFolders(ExecutionWorkspace.java:76)
	at org.eclipse.gemoc.executionframework.engine.core.ExecutionWorkspace.createExecutionContext(ExecutionWorkspace.java:72)
	at org.eclipse.gemoc.executionframework.engine.core.ExecutionWorkspace.<init>(ExecutionWorkspace.java:37)
	at org.eclipse.gemoc.executionframework.engine.commons.AbstractModelExecutionContext.<init>(AbstractModelExecutionContext.java:49)
	... 9 more

apparently, the URI uses "%20" for white space and this not correctly handled when converting to path

Clarify the use of @Step and @Main on the main entry point method

Apparently having only @main on the main entry point method does not behave the same if we also add the @step on it.

This has impact in:

• the tracemanager, if there is no @step on the main method, we do not get a big step in the trace for it,
• the stack in the debug view

If I take the Logo example (from https://github.com/dvojtise/mde-crashcourse-logo)

@Aspect(className=LogoProgram)
class LogoProgramAspect {
	@Step 												
	@InitializeModel									
	def void initializeModel(EList<String> args){
		val context = VmFactory.eINSTANCE.createInterpreterRuntimeContext
		context.turtle = VmFactory.eINSTANCE.createTurtle
		val point = VmFactory.eINSTANCE.createPoint
		point.x = 0
		point.y = 0
		context.turtle.reachedPoints.add(point)
		context.turtle.position = point
		_self.runtimeContext = context
	}
	
	@Main
	def void run(){
		val context = _self.runtimeContext as InterpreterRuntimeContext
		_self.instructions.forEach[i | i.run(_self.runtimeContext as InterpreterRuntimeContext)]
	}
}

we get this stack:

and if we add the @step too, we get

This second version (with both @step and @main) is more regular in the way we can deal with the stack. (and have a cleaner representation for its content). Additionnaly this make sure to store a value in the trace for it.
The notion of "global context" frame is more a trick that was useful in the context of the concurrent engine but does not really make sense in the context of a sequential engine. (It can represent the engine stack frame that will run the initialize method then run the main method even if it has no stored step in the trace?)

Update README

There are some dead links in the README that we should remove, and maybe a few parts that we should rewrite a little.

Add support for Melange model adaptation (wrt model conversion)

When dealing with multiples compatible languages (for ex. inheritance), GEMOC currently supports model conversion through the use of the URI of type melange:/<type>/<path>/lang=<languageIdentifier> (see http://melange.inria.fr/documentation/)

This is used in the current official sample FSM.

However, Melange is supposed to be able to support model adaptation using URI of type melange:/<type>/<path>/mt=<modelTypeIdentifier>

Using one or the other of these approach has pro and cons, especially it has has impacts on how to implement the animators.
typically: which ecore is used has base for the animator ? (MT or generated runtime language).

Additionally adaption is supposed to be enable the reuse of existing code (for example a big validation code written in java that we want to directly reuse in the execution semantic of the extended language )

when running a model and depending on the animator implementation we should select one or the other URI (or propose the choice to the end user).

At some point, the animator implementation should declare which kind of melange query it supports.

[idea] Use JavaPoet for Java code generation

https://github.com/square/javapoet

This library is basically a DSL to write Java code generators. Maintaining the GEMOC code generators (eg. trace and event management) would be much easier on the long run if we were using such a library, thanks to static checking.

gemoc-gen folder and copying the executed model

At the moment we always make a copy of the model when executing it. I believe this was originally planned as a way to keep an archive of a model next to its execution trace, but not only we are not serializing traces automatically anymore, we also don't need to make such copy when we are not tracing.

Proposal: should we remove the automated copy of the executed model?

Fail to execute model without aird for languages with inheritance

In the offical example SequentialFSM,
if we create a launch configuration that doesn't specify the animation aird, then the execution fails with an exception in the model loader

54582462 [Worker-48] ERROR fr.inria.diverse.melange.resource.MelangeDerivedStateComputer  - Fatal exception
java.lang.NullPointerException
	at fr.inria.diverse.melange.utils.EPackageProvider.getPackages(EPackageProvider.java:89)
	at fr.inria.diverse.melange.utils.EPackageProvider$1.apply(EPackageProvider.java:138)
	at fr.inria.diverse.melange.utils.EPackageProvider$1.apply(EPackageProvider.java:1)
	at org.eclipse.xtext.xbase.lib.internal.FunctionDelegate.apply(FunctionDelegate.java:42)
	at com.google.common.collect.Iterators$8.transform(Iterators.java:794)
	at com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
	at com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
	at com.google.common.collect.Iterators$5.hasNext(Iterators.java:543)
	at com.google.common.collect.AbstractMultimap.putAll(AbstractMultimap.java:82)
	at com.google.common.collect.HashMultimap.putAll(HashMultimap.java:49)
	at fr.inria.diverse.melange.utils.EPackageProvider.getPackages(EPackageProvider.java:165)
	at fr.inria.diverse.melange.ast.ModelingElementExtensions.getPkgs(ModelingElementExtensions.java:93)
	at fr.inria.diverse.melange.ast.LanguageExtensions.isTypable(LanguageExtensions.java:293)
	at fr.inria.diverse.melange.ast.ModelTypeExtensions.isComparable(ModelTypeExtensions.java:424)
	at fr.inria.diverse.melange.processors.TypingInferrer$5.apply(TypingInferrer.java:109)
	at fr.inria.diverse.melange.processors.TypingInferrer$5.apply(TypingInferrer.java:1)
	at org.eclipse.xtext.xbase.lib.internal.BooleanFunctionDelegate.apply(BooleanFunctionDelegate.java:41)
	at com.google.common.collect.Iterators$7.computeNext(Iterators.java:647)
	at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
	at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
	at java.lang.Iterable.forEach(Iterable.java:74)
	at fr.inria.diverse.melange.processors.TypingInferrer._preProcess(TypingInferrer.java:179)
	at fr.inria.diverse.melange.processors.TypingInferrer.preProcess(TypingInferrer.java:205)
	at fr.inria.diverse.melange.resource.MelangeDerivedStateComputer$1.accept(MelangeDerivedStateComputer.java:111)
	at fr.inria.diverse.melange.resource.MelangeDerivedStateComputer$1.accept(MelangeDerivedStateComputer.java:1)
	at java.util.ArrayList.forEach(ArrayList.java:1249)
	at fr.inria.diverse.melange.resource.MelangeDerivedStateComputer.installDerivedState(MelangeDerivedStateComputer.java:115)
	at org.eclipse.xtext.resource.DerivedStateAwareResource.installDerivedState(DerivedStateAwareResource.java:242)
	at org.eclipse.xtext.xbase.resource.BatchLinkableResource.getContents(BatchLinkableResource.java:148)
	at fr.inria.diverse.melange.resource.MelangeResourceImpl.getXmofURI(MelangeResourceImpl.java:457)
	at fr.inria.diverse.melange.resource.MelangeResourceImpl.adaptResourceToLang(MelangeResourceImpl.java:308)
	at fr.inria.diverse.melange.resource.MelangeResourceImpl.doAdapt(MelangeResourceImpl.java:487)
	at fr.inria.diverse.melange.resource.MelangeResourceImpl.eAdapters(MelangeResourceImpl.java:538)
	at org.eclipse.xtext.resource.XtextResourceSet$ResourcesList.inverseAdd(XtextResourceSet.java:151)
	at org.eclipse.xtext.resource.XtextResourceSet$ResourcesList.inverseAdd(XtextResourceSet.java:1)
	at org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUnique(NotifyingListImpl.java:312)
	at org.eclipse.emf.common.util.AbstractEList.add(AbstractEList.java:303)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.createResource(ResourceSetImpl.java:435)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.createResource(ResourceSetImpl.java:423)
	at org.eclipse.gemoc.executionframework.extensions.sirius.modelloader.DefaultModelLoader.loadModel(DefaultModelLoader.java:185)
	at org.eclipse.gemoc.executionframework.extensions.sirius.modelloader.DefaultModelLoader.loadModel(DefaultModelLoader.java:114)
	at org.eclipse.gemoc.executionframework.engine.commons.ModelExecutionContext.initializeResourceModel(ModelExecutionContext.java:73)
	at org.eclipse.gemoc.execution.sequential.javaengine.ui.launcher.Launcher.createExecutionEngine(Launcher.java:64)
	at org.eclipse.gemoc.executionframework.engine.ui.launcher.AbstractSequentialGemocLauncher.launch(AbstractSequentialGemocLauncher.java:106)
	at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:885)

additionnally, after such failure, when trying to create the missing aird, in a new representation file (aird), the model may stay in a strange state where Sirius fails to associate the view point to the model with the following exception

!ENTRY org.eclipse.sirius.ui 4 0 2017-09-15 09:23:01.849
!MESSAGE Error creating Representations File
!STACK 0
java.lang.NullPointerException
	at org.eclipse.gemoc.executionframework.extensions.sirius.modelloader.DebugPermissionAuthority.canEditInstance(DebugPermissionAuthority.java:58)
	at org.eclipse.sirius.ecore.extender.business.internal.permission.ReadOnlyWrapperPermissionAuthority.canEditInstance(ReadOnlyWrapperPermissionAuthority.java:95)
	at org.eclipse.sirius.diagram.business.internal.experimental.sync.DDiagramSynchronizer.refreshOperation(DDiagramSynchronizer.java:370)
	at org.eclipse.sirius.diagram.business.internal.experimental.sync.DDiagramSynchronizer.refresh(DDiagramSynchronizer.java:356)
	at org.eclipse.sirius.diagram.business.internal.sync.DDiagramSynchronizer.refresh(DDiagramSynchronizer.java:91)
	at org.eclipse.sirius.diagram.business.internal.dialect.DiagramDialectServices.refresh(DiagramDialectServices.java:271)
	at org.eclipse.sirius.business.internal.dialect.DialectManagerImpl.refresh(DialectManagerImpl.java:115)
	at org.eclipse.sirius.business.internal.dialect.DialectManagerImpl.refresh(DialectManagerImpl.java:106)
	at org.eclipse.sirius.diagram.business.internal.dialect.DiagramDialectServices.createRepresentation(DiagramDialectServices.java:193)
	at org.eclipse.sirius.business.internal.dialect.DialectManagerImpl.createRepresentation(DialectManagerImpl.java:153)
	at org.eclipse.sirius.diagram.tools.api.command.view.CreateDiagramWithInitialOperation.execute(CreateDiagramWithInitialOperation.java:98)
	at org.eclipse.sirius.business.api.helper.task.TaskExecutor.execute(TaskExecutor.java:64)
	at org.eclipse.sirius.tools.api.command.SiriusCommand.doExecute(SiriusCommand.java:80)
	at org.eclipse.emf.transaction.RecordingCommand.execute(RecordingCommand.java:135)
	at org.eclipse.emf.workspace.EMFCommandOperation.doExecute(EMFCommandOperation.java:119)
	at org.eclipse.emf.workspace.AbstractEMFOperation.execute(AbstractEMFOperation.java:150)
	at org.eclipse.core.commands.operations.DefaultOperationHistory.execute(DefaultOperationHistory.java:488)
	at org.eclipse.emf.workspace.impl.WorkspaceCommandStackImpl.doExecute(WorkspaceCommandStackImpl.java:208)
	at org.eclipse.emf.transaction.impl.AbstractTransactionalCommandStack.execute(AbstractTransactionalCommandStack.java:165)
	at org.eclipse.emf.transaction.impl.AbstractTransactionalCommandStack.execute(AbstractTransactionalCommandStack.java:219)
	at org.eclipse.sirius.diagram.business.internal.dialect.DiagramDialectServices.initRepresentationForElement(DiagramDialectServices.java:354)
	at org.eclipse.sirius.business.api.dialect.AbstractRepresentationDialectServices.initRepresentations(AbstractRepresentationDialectServices.java:546)
	at org.eclipse.sirius.business.api.dialect.AbstractRepresentationDialectServices.initRepresentations(AbstractRepresentationDialectServices.java:497)
	at org.eclipse.sirius.diagram.business.internal.dialect.DiagramDialectServices.initRepresentations(DiagramDialectServices.java:334)
	at org.eclipse.sirius.business.internal.dialect.DialectManagerImpl.initRepresentations(DialectManagerImpl.java:360)
	at org.eclipse.sirius.business.internal.session.danalysis.DViewOperations.createView(DViewOperations.java:128)
	at org.eclipse.sirius.business.internal.session.danalysis.DAnalysisSessionImpl.createView(DAnalysisSessionImpl.java:1139)
	at org.eclipse.sirius.business.api.session.ViewpointSelector.selectViewpoint(ViewpointSelector.java:79)
	at org.eclipse.sirius.ui.business.api.viewpoint.ViewpointSelectionCallback.selectViewpoint(ViewpointSelectionCallback.java:40)
	at org.eclipse.sirius.ui.business.internal.commands.ChangeViewpointSelectionCommand.doExecute(ChangeViewpointSelectionCommand.java:112)
	at org.eclipse.emf.transaction.RecordingCommand.execute(RecordingCommand.java:135)
	at org.eclipse.emf.workspace.EMFCommandOperation.doExecute(EMFCommandOperation.java:119)
	at org.eclipse.emf.workspace.AbstractEMFOperation.execute(AbstractEMFOperation.java:150)
	at org.eclipse.core.commands.operations.DefaultOperationHistory.execute(DefaultOperationHistory.java:488)
	at org.eclipse.emf.workspace.impl.WorkspaceCommandStackImpl.doExecute(WorkspaceCommandStackImpl.java:208)
	at org.eclipse.emf.transaction.impl.AbstractTransactionalCommandStack.execute(AbstractTransactionalCommandStack.java:165)
	at org.eclipse.emf.transaction.impl.AbstractTransactionalCommandStack.execute(AbstractTransactionalCommandStack.java:219)
	at org.eclipse.sirius.ui.business.api.viewpoint.ViewpointSelection$8.run(ViewpointSelection.java:489)
	at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:119)

In order to successfully be able to add the view points and patch the launch configuation, we need, at minimum, to close and re-open the project containing the model (or more radically, restart eclipse 😉 )

steps to reproduce the issue:

• install fsm example language and model in their respective workbenches
• in the modeling workbench, copy a model that usually work (only the .fsm) create a launch configuration for it without specifying the aird.
• launch the model (debug mode) -> crash
• then right click on the fsm and try to create a representation and select the FSM and XFSM view points.

Missing clear explanation about where to set the "aspect" annotation in order to enable the trace manager and omniscient debugger

There is no documentation about how and where the language designer should place the "aspect" EAnnotation in order to define the runtime data.

Should the annotation be put on the EAttributes, EReferences, EClasses? Does some of them is enough or should the language designer tag all the structure? (for example does tagging an EClass is enough and so we don't have to tag its Eattributes ?)

This job is partly done when using melange but there is no direction about doing it manually. (

This is quite important since missing to tag some concept may lead to errors such as those in #85

Make sure we can execute/trace/debug models without using Melange at all

Variable view does not scale correctly with models with a lot of new RTD

The current Variable view is flat. It displays all Runtime data at the root of the view.
This doesn't scale correctly for languages with a lot of RTD or that create a lot of new RTD.

for example in the Logo (complete code in dvojtise/mde-crashcourse-logo)

The variable view grows by adding new segments to the drawing board. It is impossible to interpret the data displayed there especially after a high number of steps.

I suggest that the view should display only RTD which are not already contained (directly or indirectly) by another RTD. Thus the view should display only "root" RTD and use the nesting to display the rest.

Note1: the yellow highlighting about the last modified values should unfold the tree in order to focus on the appropriate data.
Note2: the same problem also occurs on the Multidimentionnal timeline which should probably take a similar nesting approach

Improve feedback for simple loading errors

In order to avoid reports such as gemoc/MODELS2017Tutorial#3
It would be useful to have better error reporting of the model loader error.

A simple trick would be to send the exception message directly in the main console (the full stack trace would remain in the error log as usual) in most case this should be enough to guide the user.

Proposal: refresh all sirius layers by default + simplify declaration of layers to refresh

At the moment, the GEMOC animator requires the language engineer to explicitly declare which layers to refresh by extending the AbstractGemocAnimatorServices class. Example:

public class FsmAnimatorServices extends AbstractGemocAnimatorServices {
	@Override
	protected List<StringCouple> getRepresentationRefreshList() { 
		final List<StringCouple> res = new ArrayList<StringCouple>();
		res.add(new StringCouple("FSM", "Animation"));
		return res;
	}
}

This leads to a few problems:

• If he/she forgets to declare such layers, there is no animation at all by default
• It's a little tedious to write java code just to declare a couple of string
• There is no checking/feedback on whether the declared layers do exist and are valid

Proposal:

• Refresh all animations layers by default (change to make in AbstractGemocAnimatorServices)
• Allow the language engineer to override this default behavior by declaring which layers should only be refreshed, and allow him/her to do that in the .dsl file instead of using Java code. This could in addition give the possibility to add an Xtext checker to verify whether the given layers are valid.

Incomplete documentation about Trace generator or remove trace generator feature ?

The Trace generator documentation is currently incomplete
(see http://download.eclipse.org/gemoc/docs/nightly/userguide-lw-provide-language-with-tools.html#defining-multidimensional-trace-project-section and its source https://github.com/eclipse/gemoc-studio-modeldebugging/blob/master/trace/generator/plugins/org.eclipse.gemoc.trace.gemoc.ui/docs/asciidoc/user_lw_GenerateTraceMetamodel.asciidoc )

However, when discussing with @d-leroy, it appears that the generic trace is as efficient as a language specific one. (When writing https://www.sciencedirect.com/science/article/pii/S0164121217302765 they decided to not include the language specific one due to small performance difference with the generic one)
Does it make sense to keep both the generic trace and the generator ? is there any reason to keep the code of the generator ?

We should decide if we

• a/ keep the generator but then we need to complement the documentation (including comparison with the generic one)
• b/ or simply remove the generator (then update the documentation but only about the use of the generic trace in the modeling workbench, not about generating it and compare it with the generic one)

State graph displays incorrect graphs

Displayed state graph can show states with several outgoing transitions and only one incoming transition, without being part of a cycle, which is incorrect: a state visited only once can only have one outgoing transition.

This can be due to several reasons:

• The visual representation in JavaFX can be incorrectly updated, displaying "ghost transitions"
• The underlying data structure storing the graph can be incorrectly updated when the execution trace changes
• The computation of the state equivalency classes of the execution trace can be incorrect

Multidimensionnal timeline hovering not showing correctly

At least on my system (ubuntu 18) the hovering in the multidimensionnal timeline is not very reliable

It may open very far from the point where the user was hovering (in worst cases, it can be outside of the whole eclipse workbench !)

Additionally:

• it would be useful to have a real popup action to show the same information instead of having to wait for it, using this action would open a "real" window" from which we can copy/paste or take more time to read its content before it disappears.

Final state of an execution is not correctly displayed

In order to be able to step back in the history the recording of the execution stops before the last step even if it as been executed.
This leads to incorrect/misleading information in the UI.

For example when using the K3FSM official example, an do a Run/Resume up to the end
we obtain:

We can see that the execution correctly reached the end because the console shows that the whole string has been consumed. However, the variable view still show the penultimate state (same for the stack)
The timeline looks correct but is stuck to the penultimate step (7). (the hovering shows the correct information when hovering on step 8 in the timeline)

It would be clearer for the user to introduce a virtual "End" step (similar to the virtual "Initialize Model" step) that would simply copy the content f the last step but will help to indictate that even if the engine is not stopped, the execution reached it end (according to its semantic)

Ideally these virtual steps would have a special representation in the timeline in order to clearly identify them.

This virtual step would also help in the modeling workbench test in order to know if the simulation has reached the end by looking in the engine execution context.

Mutidimentional timeline fails to restore states on complex RTD

Working on logo (https://github.com/dvojtise/mde-crashcourse-logo/tree/master/part3-mmfirst-solution), it seems that the multidimensional timeline fails to correctly restore the RTD when clicking back in the timeline.

(note: even after applying the #94)

Apparently, it works correctly with the FSM.

As FSM has a flat RTD layout (all RTD attributes are directly hosted by an object from the static structure) , I'm wondering if someone has already tried to use the restoreState on complex RTD

ie. some runtime object containing nested runtime objects and nested runtime attributes
In the case of Logo, I have a structure where everything bellow runtimeContext is marked with @aspect :

Program 
   runtimeContext : RuntimeContext
RuntimeContext
   turtle : Turtle
   reachedPoints : Point
   segments : Segment
Turtle
    position : Point
    heading 
Point
    x
    y    
Segment
   origin : Point
   dest : Point
...

Generic trace addon does not deal with several primitive ecore types such as EShort, EByte, ...

For my simulation (Logo) I need to code some attributes using EDouble in order to have correct precision in the simulation.

When enabling the generic trace addon, it fails with various messages (going from null pointer to 'no null' constraint is violated)

When analysing the error I looked into GenericTraceConstructor class which apparently does not deal with various Ecore primitive type such as EDouble

for example: getGenericValue or addNewObjectToState

Create domain Model wizard does not take into account previous value from template

when creating a new sequential project, it creates a .dsl file with the following content:

name = org.eclipse.gemoc.example.k3fsm.K3fsm
ecore = platform:/resource/ecoreFilePath
k3 = qualified.class.name

then when trying to create a domain model project, it simply add a new value to the ecore entry

something like:

ecore = platform:/resource/ecoreFilePath,platform:/resource/org.eclipse.gemoc.example.k3fsm/model/k3fsm.ecore

It would be useful to detect that this value is actually a dummy value coming from the template and replace it with the new one.
Adding the value is still good but for next calls to the wizard of if it doesn't recognize the template.

Step to reproduce:

• File > New > Gemoc Sequential Xdsml project, Finish
• right click on the project, GEMOC Language > Create Domain Model Project for Language

format command for splitting long lines of .dsl file

Currently, the .dsl file generated by several tools use a single line presentation for all key-values

This is not really convenient for k3 key which lists all aspect classes it uses.

it could be improved by highlighting the fact that dsl file format supports the use of \ in order to break lines.
for example:

name = org.eclipse.gemoc.sample.legacyfsm.xsfsm.XSFSM
ecore = platform:/resource/org.eclipse.gemoc.sample.legacyfsm.xsfsm.xsfsm/model/XSFSM.ecore
k3 = org.eclipse.gemoc.sample.legacyfsm.xsfsm.xsfsm.aspects.StateAspect,org.eclipse.gemoc.sample.legacyfsm.xsfsm.xsfsm.aspects.StateMachineAspect,org.eclipse.gemoc.sample.legacyfsm.xsfsm.xsfsm.aspects.TransitionAspect

would become:

name = org.eclipse.gemoc.sample.legacyfsm.xsfsm.XSFSM
ecore = platform:/resource/org.eclipse.gemoc.sample.legacyfsm.xsfsm.xsfsm/model/XSFSM.ecore
k3 = org.eclipse.gemoc.sample.legacyfsm.xsfsm.xsfsm.aspects.StateAspect,\
   org.eclipse.gemoc.sample.legacyfsm.xsfsm.xsfsm.aspects.StateMachineAspect,\
   org.eclipse.gemoc.sample.legacyfsm.xsfsm.xsfsm.aspects.TransitionAspect

Ideally, the command should be mapped to the classic right click -> Source -> format popup menu (and Ctrl + Maj + Click)

Offer the possibility to use different objects for the @initialize and @main

In some languages (such as ThingML) It would be nicer to have the @initialize method directly on the main container, but use an @main on another kind of object.

This would lead to a slightly different launcher where the user will have to select both the object for the initialization action and another object for starting the execution (main). This could be optional( some check-box in the launcher)

[ExeFramework] Task: move sequential+omniscient debugger to exeframework

(copied from gemoc/gemoc-studio-old#47)

Currently, the sequential and omniscient debuggers are stored with the java engine code in the plugin org.gemoc.execution.sequential.javaengine.ui.

Since these debuggers are (almost) independent of the considered execution engine, they should be moved in the execution framework, so that they are more explicitly commonly shared among all engines, and to have cleaner dependencies.

Use GEMOC ANR Documents to improve GEMOC documentation about model animation and debug component

As stated in the note in http://download.eclipse.org/gemoc/docs/nightly/_components_documentation.html#_simulation_model_animation_framework, the document http://gemoc.irisa.fr/ins-pub/m30/gemoc-anr-d4.3.1-v1.0.pdf from GEMOC ANR project contains several sections that would be useful to move to the documentation.

Even if this document is quite old this part of the framework hasn't changed much, so the verification and adaptation should be easy.

New GEMOC project creates project with warnings

When doing a New GEMOC sequential xDSML project, the resulting project has some warning that could be easily avoided:

• Automatic-Module-Name' header is required for Java 9 compatibility
• The JRE container on the classpath is not a perfect match to the 'JavaSE-1.7' execution environment

CreateNewGemocSequentialLanguageProject should not directy inherit from NewMelangeProjectWizard

CreateNewGemocSequentialLanguageProject currently inherits from NewMelangeProjectWizard

This was making sense when there were only melange as input, but now we are considering other project structure (such as DSL file + k3 only, xmof, ...)
so now it would be better to have a new GEMOC project that would be "technology" agnostic, then have templates (contributed as extension like current ones) that would finalize the project with appropriate content and natures.

Note: in case of reuse between related templates, they can inherit of a common base or use a composition approach

incorrect addon extension point declaration

in http://download.eclipse.org/gemoc/docs/nightly/_contributing.html#_developing_new_addons
, it explains that we can click on Class*: in the extension editor to create the initial version of a class implementing IEngineAddon

The procedure is correct but the generated file imports org.eclipse.gemoc.gemoc_language_workbench.api.engine_addon.IEngineAddon instead of org.eclipse.gemoc.xdsmlframework.api.engine_addon.IEngineAddon

The fix is relatively simple: remove the wrong import and use Eclipse quickfix to add the correct import statement.

The exsd file declaring the extension point must probably be reviewed.

(note, if looking into his exsd, we should also check to other GEMOC extension points ...,
for example also adding some descriptions as it is displayed by the plugin editor wizard)

IEngineAddon.engineStarted method called 2 times on start

For a given language specific IEngineAddon (ie. declared in XDSML_Definition tag of the plugin.xml of the xdsml project)

The addon method engineStarted is called 2 times instead of one.

(I haven't checked with engine addon that is not language specific)

To reproduce this issue, one can take https://github.com/dvojtise/mde-crashcourse-logo/tree/master/part3-mmfirst-solution projects and then modify the https://github.com/dvojtise/mde-crashcourse-logo/blob/master/part3-mmfirst-solution/fr.inria.sed.logo.xdsml/src/fr/inria/sed/logo/xdsml/ui/turtleboard/TurtleBoardEngineAddon.java method engineStarted by removing the if(turtleGUI != null) { test which is a workaround for this issue.

Provide tests for the modeling workbench

We currently have some system-level tests running for the features of the language workbench, ie. creating, compiling, importing languages (see https://github.com/eclipse/gemoc-studio/tree/master/gemoc_studio/tests).

We would also need automated tests for the features of the modeling workbench, ie. executing and debugging models. Technically, this is a little tricky, because it means we must deploy languages in the studio compiled for testing purposes, and run tests for these languages. But this is nothing Maven and Tycho cannot handle.

Some preliminary automation work was achieved here for the generic framework, and here specifically for the java engine, which can probably be reused.

At first glance, most importantly we should test:

• each execution engine (if possible with a common test suite for engines), which for the most part consists of checking that the engine sends the correct notifications to its addons, and at the right instants
• each addon, where in this case each addon would have its own test suite focusing on the services provided by the addon (eg. checking that a correct trace is built by the generic trace constructor, or that the stepping services provided by the debugger work well)

Then of course UI testing would be great as well to check that we have the menus and buttons for everything.

Language specific IEngineAddon cannot be disabled in launch configuration

In Gemoc, IEngineAddon can be either generic or language specific.
(see TIP in https://download.eclipse.org/gemoc/docs/nightly/_contributing.html#dev-new-addons)

When declared as language specific, the addon is launched only for the given engine+language tuple.

However, in this case the Engine Addons tab is not aware of such addons and does not propose any way to disable it.

Ie. the Engine Addons tab should shows language specif addons for the current language as set in the Main tab.

An example to test this is available in https://github.com/dvojtise/mde-crashcourse-logo/tree/master/part3-mmfirst-solution (see the xdsml project)

[feature] Declaring options in addons

At the moment, addons can only be enabled or disabled.

We should consider giving the possibility to addons to declare options that could then be configured in the launch UI.

This would avoid hard-coded disabled addon features (see #22)

Animation is refreshed before a step, but not right after?

In the animator we do refresh the diagrams before each execution step, but not after, see here:

gemoc-studio-modeldebugging/framework/execution_framework/plugins/org.eclipse.gemoc.executionframework.extensions.sirius/src/org/eclipse/gemoc/executionframework/extensions/sirius/services/AbstractGemocAnimatorServices.java

Lines 402 to 403 in 243dd4c

	public void stepExecuted(IExecutionEngine<?> engine, Step<?> stepExecuted) {
	}

Is there a reason for this? If I am correct (and after some testing on my end), this means that with the concurrent engine, when the engine is paused while we are "about to choose" a step, the graphical view was never refreshed after the last step that was executed, which means we always see the model one step earlier than we should.

Was there a reason originally for this choice, maybe performance? If that is the case, then in fact it would be more logical to refresh after each step, since chances made to the runtime data only occur in steps (including initialization).

cryptic error when running a model not supported by the language

When running a model for a language that is not supported (either directly or via melange adaptation) the error is not self explanatory : this is currently a stack trace such as:

java.lang.RuntimeException: java.lang.IllegalArgumentException: argument type mismatch
	at org.eclipse.gemoc.execution.sequential.javaengine.PlainK3ExecutionEngine.executeEntryPoint(PlainK3ExecutionEngine.java:283)
	at org.eclipse.gemoc.executionframework.engine.core.AbstractSequentialExecutionEngine.performStart(AbstractSequentialExecutionEngine.java:86)
	at org.eclipse.gemoc.executionframework.engine.core.AbstractExecutionEngine.startSynchronous(AbstractExecutionEngine.java:333)
	at org.eclipse.gemoc.executionframework.engine.core.AbstractExecutionEngine$1.run(AbstractExecutionEngine.java:316)
	at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalArgumentException: argument type mismatch
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.eclipse.gemoc.execution.sequential.javaengine.PlainK3ExecutionEngine.executeEntryPoint(PlainK3ExecutionEngine.java:271)

We should, a minima, propose a better message that indicates which object was passed as argument versus the expected one (full java name should help)

In addition, the launcher can be improved in order to clearly indicate the issue before launching the model.

Note : this error is quite recurrent especially since the process of building a simple language is not correctly documented compared to the process of build 2 languages via extension (see user who had related issues : gemoc/gemoc-studio-old#59 gemoc/gemoc-studio-old#61 )

Disabled breakpoints still pause the execution

In the Modeling workbench with an executable language with debug support (as defined in https://download.eclipse.org/gemoc/docs/nightly/userguide-lw-provide-language-with-tools.html#defining-a-debug-representation-section),
if one adds a breakpoint on a model element, then goes to the Breakpoints view and uncheck it then the execution will pause on the breakpoint even if should continue.

Tested on https://github.com/dvojtise/mde-crashcourse-logo/tree/master/part3-mmfirst-solution example
then use a long running model (for example "flower.logo")

Note: the Gemoc -> toggle breakpoint action accessible with a right click in the model works during execution, but it completly removes it (not just disable)

Move the Java Engine code to its dedicated repository

Similarly to the ALE Engine code which is in its own repository (https://github.com/eclipse/gemoc-studio-execution-ale) the Java Engine code should go in its own repository too.

Note: the repository has already been created https://github.com/eclipse/gemoc-studio-execution-java

Some views are not in the correct group and not available in the Show view shortcut

When opening view (Windows > Show view > Other...) Some GEMOC views are not located in the correct category:

• Event Manager
• State Graph view

In addition the shortcut to opening views when using the Debug perspective does not show the State Graph view

and last point, the GEMOC category is not written in all uppercase.

Breakpoints view not documented

Adding a breakpoint is possible in the studio and is partially documented
however there is nothing about the Breakspoints view

this should explain what is the use of the cryptic parameters "Brea on Logical step" and "BReak on MSE" (or lead to some cleanup)

[ModelDebugging] Task: make the sequential debugger aware of ParallelSteps

(copied from gemoc/gemoc-studio-old#45)

The sequential debugger (org.gemoc.execution.sequential.javaengine.ui.debug.GenericSequentialModelDebugger) is currently considering that all big steps are sequentials, ie. that we can step into them, and stack them.

However, if a ParallelStep occurs, it should be treated differently: we cannot step into them, and the SmallSteps it contains should not be stacked .

After discussion, we decided to make the debugger treat a ParallelStep similarly to a SmallStep: it is atomic, and therefore cannot be stepped into.

Clarify stack content in Debug view

In conjunction with #87 and #88, the Debug view and its stack can be improved and clarified.

1/ clarify context / instruction
More specifically, there is currently a mix of the notion: context and instruction that are defined in IDSLDebugger.pushStackFrame (

gemoc-studio-modeldebugging/simulationmodelanimation/plugins/org.eclipse.gemoc.dsl.debug.ide/src/org/eclipse/gemoc/dsl/debug/ide/IDSLDebugger.java

Line 344 in 9062e18

void pushStackFrame(String threadName, String frameName, EObject context, EObject instruction);

)

Current we alway put the same EOject in both. However, if we look to classic java debugger, we can see that there is a distinction: the context is (for example) the procedure and the instruction, the "line" in the procedure.
Applied similarly to a GEMOC language such as Logo, we currently have:

As this is a sequential language we can take the opportunity to use the containment information of the model elements to infer a more precise instruction. Thus selecting the Block as in the picture, would actually indicate: [Block] fr§.inria.sed.logo.BlockImpl@5476c6 -> run() {2} where the {2} indicates that we are on the second instructions of the block. As the instruction is more precise, the selected element in the editor (graphical or textual) would be the selected instruction. (right 90 in this example)
This kind of display would help to correctly deal with the data changed information (in yellow in the Variable view).

2/ clarify "global context"

The Global context could also be improved in order to behave in the same way as other stack elements: display the name of the method being run (in the example main()) and a possible current instruction ({3} as the third instruction of the logo program -> repeat 4 in the example)

3/ clarify "future instruction" stack frame
Last, the stack frame [Right] fr.inria.sed.logo.impl.RigthImpl@7cbd11ad -> run() is actually a representation of the future instruction but does not have a context yet. Compared to java debugger, this frame does not exist in java debugger.
However, while representing the future is quite interesting (especially when thinking to concurrent engines), the fact that it is represented in the same way as the other stack frames is misleading. I suggest finding a way to display it differently (icon overlay and/or italic font). Once correctly identified we can imagine extensions such as popup or dropdown giving the possibility to show alternative future (injected events from the behavioural interface or alternative solutions from the concurrent solver)

DSL file in src folder leads to incorrect deployment

Similarly to #25 a dsl file in a src folder also leads to similar issue:
the XDSM_Definition may also be corrupt for the same causes

for example with the official K3FSM example:

<XDSML_Definition name="org.eclipse.gemoc.example.k3fsm.K3fsm" 
xdsmlFilePath="platform:/plugin/org.eclipse.gemoc.example.k3fsm.xdsml/target/classes/org/eclipse/gemoc/example/k3fsm/K3fsm.dsl" 
modelLoader_class="org.eclipse.gemoc.executionframework.extensions.sirius.modelloader.DefaultModelLoader" />

is not correct at deploy time (in a jar)

and

<XDSML_Definition name="org.eclipse.gemoc.example.k3fsm.K3fsm" 
xdsmlFilePath="platform:/plugin/org.eclipse.gemoc.example.k3fsm.xdsml/src/org/eclipse/gemoc/example/k3fsm/K3fsm.dsl" 
modelLoader_class="org.eclipse.gemoc.executionframework.extensions.sirius.modelloader.DefaultModelLoader" />

is correct only if the src folder has been added in the bin.includes of the build.properties file. But adding this manually is counter intuitive for most users.

Since the dsl file is not related to java compilation (as opposed to melange file of #25)
I suggest to find a better convention for storing the dsl files in the project. Ie. not in a "src" folder

note: currently when melange generates the dsl file for a new runtime language, it puts it in the /model folder next to the .ecore and .genmodel. So why not using the same folder name : model ? (ie. the dsl file is the model representing the language definition...)

Suggestions and comments are welcome.

Provide checkers for ecore/ALE/k3/... entries (via extension point) for dsl file content

The new dsl file does not report any error or warning for files such as

name = org.eclipse.gemoc.example.k3fsm.K3fsm
ecore = platform:/resource/ecoreFilePath,platform:/resource/org.eclipse.gemoc.example.k3fsm/model/k3fsm.ecore
k3 = qualified.class.name

As dsl file is an extensible format we need to set up a mechanism so the check can be contributed by component.

In this case: the general GEMOC framework should provide a check about the ecore entry and the k3 entry in order to verify that it correctly indicates a existing resources.