gemoc / gemoc-studio-old Goto Github PK

from https://gforge.inria.fr/tracker/index.php?func=detail&aid=19839&group_id=4645&atid=13885

Listing links in the documentation doesn't work correctly, they display ??? instead of the correct link
however they seem to jump to the correct location

From https://gforge.inria.fr/tracker/index.php?func=detail&aid=20039&group_id=4645&atid=13885

the ModelID information is used in several places
to define the DebugRepresentation and its possible customisation for concurrent and Sequential but also to determine if the execution must pause on a breakpoint
but this leads to several issues :
if the id are different for Concurrent and Sequential in order to provide diffrent presentation customisation this implies that the breakpoint are different too, so a given breakpoint on a sirius diagram that can be executed in both sequential and concurrent must be repeated with both modelId in order to be taken into account at runtime. the external java action in the sirius odesign must be adapted accordingly too, the sirius service should be adapated too.

Ideally, a single modeId should be used so the odesign UI will be the same for both engines. However in this case we need to find a way to customize the debug presentation (for the Debug Stack and for the Variable view)

From [#16345] https://gforge.inria.fr/tracker/index.php?func=detail&aid=16345&group_id=4645&atid=13870

In the first version of the studio, we plan offer to the modeler only the languages defined in the language workbench (as language project).
If one wish to propose an alternative Mocc or DSE for a given AS, he will need to duplicate the language project with another name.
In the modeling workbench, it would be nice if we can use the osgi provisionning, to be able to build a variant of a given language in the background and then deploy it dynamically.

Proposed scenario :

• user select an existing language, in the run configuration, ask for (for example) a dynamic mocc alternative. In the back ground duplicate the language definition with a new language name, change the mocc, compile this new language as a jar, and provision it in the user workbench so he will be able to run his model with this language (dynamic) alternative.

In concurrent mode, in the "Stimuli manager" view, there is the possibility to add a breakpoint on an MSE. This break will never happen.

With the current code, this will never work for two reasons:

• This stores a breakpoint for the timesquare object "fr.inria.aoste.timesquare.ecl.feedback.feedback.impl.ModelSpecificEventImpl", and not for the corresponding GEMOC object "fr.inria.diverse.trace.commons.model.trace.MSE"
• The concurrent debugger only calls shouldBreak on the starting Step, and never on the MSEOccurrence that may trigger this step

To fix this problem, we must find the underlying MSE when creating breakpoints, and we must fix how breakpoints are checked in concurrent mode.

something like http://eclipse.org/gemoc/<mon_metamodel_gemoc>/<mes_sous_packages_optionnel>

from https://gforge.inria.fr/tracker/index.php?func=detail&aid=18405&group_id=4645&atid=13870

When creating a new modeling project, the wizard should:

1. ask for the language(s) to use -> store the information somewhere
2. create default model(s)
3. maybe open the created models?

from https://gforge.inria.fr/tracker/index.php?func=detail&aid=19831&group_id=4645&atid=13885

In the TFSM concurrent,

if we jump backward, then branch, the branch is not aligned to the original (slightly back)

for example, on a test on simple_example tfsm , the number 98 of the new branch is aligned with the number 96

in Melange new project template , when entering manually a string in the fields: Ecore file location and DSA project the cursor moves to the beginning of the string on each character, the resulting string is a reversed version of what the user have typed.

(note: this is similar to bug in other older GEMOC wizards that have been fixed now)

When creating a ECL project it is possible to leave the "Root container model element" empty.
Also the SELECT button does not work and so I had to enter the information by hand.

from https://gforge.inria.fr/tracker/index.php?func=detail&aid=20151&group_id=4645&atid=13885

in the different engines (concurrent and sequential) the way to print method call on a given object is not the same in all views.

look into : Debug stack ( use step into in concurrent) Logical step view, multibranch timeline, Multidimentional Timeline

If possible it should use something similar to the print convention used in the variable view ? (ie. inspired from UML)

from https://gforge.inria.fr/tracker/index.php?func=detail&aid=18219&group_id=4645&atid=13870

https://www.eclipse.org/rcptt/
evaluate if RCP TT can be used to automate some of our integration tests

from https://gforge.inria.fr/tracker/index.php?func=detail&aid=16909&group_id=4645&atid=13870

it should be possible to develop only the required concerns of a language (only editor, or only simulator, etc.). All the language concerns should thus be optional.

-> this implies that the plugin.xml and the schema used need to be relaxed so we don't have error for non complete language.
However, some check must be done before execution and allow to run only language that offers the required elements

Currently, we have three implementations of the Eclipse extension point called org.eclipse.debug.ui.debugModelPresentations:

• org.gemoc.execution.sequential.javaengine.ui.debugModel with the class org.gemoc.execution.sequential.javaengine.ui.launcher.PlainK3DebugModelPresentation
• org.gemoc.execution.concurrent.ccsljavaengine.ui.debugModel with the class org.gemoc.execution.concurrent.ccsljavaengine.ui.launcher.GemocDebugModelPresentation
• org.gemoc.gemoc_heterogeneous_modeling_workbench.ui.debugModel with the class org.gemoc.gemoc_heterogeneous_modeling_workbench.ui.launcher.GemocDebugModel

This separation makes it possible to customize how the stack and other debugging elements are presented. However, the differences between these classes seem small.

In addition, these three "debugModel" identifiers are used in the code to separate some of the debugging logic (eg. a breakpoint it tied to such an id, meaning a sequential breakpoint does not work in concurrent mode).

After discussion, we decided to switch to a single id and a single implementation of the eclipse extension point. This ID should be provided by the GEMOC framework, and should probably be used by default in the AbstractExecutionEngine.

Hi Gemoc team,

I followed each step in the Tutorial of MarkedGraph example, however after I created launch configuration as in step 5.5, an error message popped up as follow:
"Error occured when starting execution engine: org.eclipse.core.internal.resources.ResourceException: Resource '/org.gemoc.sample.markedgraph.sample/gemoc-gen/wikipedia.timemodel' does not exist. "
also in Console I see: "QVTo file not correctly specified in plugin.xml, please verify your language specification"

I noticed that when setting up debug configuration my Melange languages menu was empty, I had to pasted org.gemoc.sample.markedgraph.xdsml.MarkedGraphL manually. I guess something is wrong with my MarkedGraphL.ecl file but I don't know what could be the problem. I'm using version 2.2.0. Have any idea what caused the error?

Thx

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.

During the startup of the first sequential model execution (apparently only when using a textual syntax), a call to org.gemoc.bcool.model.xtext.ui.BCOoLExecutableExtensionFactory.getInjector() is made, which slows down startup by roughly 5s.

from https://gforge.inria.fr/tracker/index.php?func=detail&aid=20139&group_id=4645&atid=13885

the .melange file is referenced in the plugin.xml in order to be able to retreive it from the modeling workbench.

Strangely, the path used may change overtime, sometime this is /src sometime this is /bin that is indicated in the plugin.xml

this is annoying when using git, because the file changes for nothing

more important, neither src nor bin are correct
if these files exists when running in development mode (ie. 2 eclipses) if the language is deployed in an eclipse (in order to be used by a Model Designer) neither src nor bin exists in the final jar.
adding src in the build would be a workaround but this is usually not a good idea to add this folder in the jar (because in general, it would also include all other java and xtend source), a copy in dedicated folder would be much better.

Currently, a GEMOC breakpoint (org.gemoc.executionframework.engine.ui.debug.breakpoint.GemocBreakpoint) on a model element can be declared to:

• pause when an MSE occurrence starts that targets that element (BREAK_ON_MSE_OCCURRENCE)
• pause when a logical step starts, if it contains an MSE occurrence targeting that element (BREAK_ON_LOGICAL_STEP)

This is legacy, due to how breakpoints were designed for the purely concurrent former GEMOC Studio. In fact, these booleans are nowadays only used in concurrent mode (although they are not working properly, since checks are not done correctly, partly related to #42).

I would suggest to at least remove these booleans from the common generic GemocBreakpoint class, since they are irrelevant in the sequential case.

In addition, BREAK_ON_LOGICAL_STEP can probably be renamed BREAK_ON_PARALLEL_STEP.

Hi there. In order to locate the NullPointerException problem I mentioned in the last post, I downloaded the source codes of ModelDebugging-master and imported them into my workspace. It immediately gave a lot of "cannot be resolved" errors. I was able to correct some of them by downloading the plugins shown with a red cross in manifest/dependencies/required plug-ins. After download the plugins I put them into the plugins directory of Gemoc. However, I can't fix the same kind of error of the following plugins:

org.eclipse.epsilon.common
org.eclipse.epsilon.ecl.engine
org.eclipse.epsilon.emc.emf
org.eclipse.epsilon.eol.engine

Although I already put thoses plugins under the plugin directory of Gemoc, the errors are still there:

Bundle 'org.eclipse.epsilon.common' cannot be resolved
Bundle 'org.eclipse.epsilon.ecl.engine' cannot be resolved
Bundle 'org.eclipse.epsilon.emc.emf' cannot be resolved
Bundle 'org.eclipse.epsilon.eol.engine' cannot be resolved

These errors really drives me crazy. Plz plz give me some suggestions. Thanks in advance.

On MacOS the name of the application is Eclipse.app even if the zip is correctly named gemoc studio

this leads to some inconstancy when installing the tool with standard mac application and can replace Eclipse installation instead of GEMOC Studio installation (this prevent from being able to easily use both Eclipse and GEMOC Studio at the same time)

from https://gforge.inria.fr/tracker/index.php?func=detail&aid=18412&group_id=4645&atid=13870

http://www.yourkit.com/purchase/

Open Source Project License

The license is granted to developers of non-commercial Open Source projects, with an established and active community. The license is free. However, we ask you to add a reference to YourKit website on the web pages of your Open Source project.

we should also use the profiler in Sirius (activation in the preferences, then open the dedicated view)

from https://gforge.inria.fr/tracker/index.php?func=detail&aid=16311&group_id=4645&atid=13870

while calling the wizards of the process we need some more detailled explanation.
We probably need 2 kind :

• possibility to (or automatically ) open the help view on the appropriate section in Gemoc documentation
• on gemoc specific wizards (for ex, the action selection wizard), have a right column displaying the documention of the wizard (extracted/excerpt from Gemoc help documentation)

from https://gforge.inria.fr/tracker/index.php?func=detail&aid=20035&group_id=4645&atid=13870

the package in the template should use a name derived from the project name ie.

if we have org.company.my_language.xdsml
the package name should be org.company.my_language

note: sequential and concurrent version does not behave the same !! one propose org.company, the other proposes org.company.my_language.xdsml
the minimum solution would be that they both propose the same

note2: there is a helper that is able to compute that (used to compute the project name proposal when creating project dsa, sirius, etc)

from https://gforge.inria.fr/tracker/index.php?func=detail&aid=19771&group_id=4645&atid=13870

possibility to restrict the use of some addons to only some languages
Typically the trace Addon should be restricted to the language it is intended to.
At miminum they should be disabled in the UI or invisible.
(Currently they are proposed in every launch)

from https://gforge.inria.fr/tracker/index.php?func=detail&aid=19685&group_id=4645&atid=13870

In the launchconfiguration, when selecting a model and a language, it should be possible to show an error if these elements aren't compatible.
Advanced approach : take care of its real content and possible conversion thanks to Melange

from https://gforge.inria.fr/tracker/index.php?func=detail&aid=16938&group_id=4645&atid=13870

The "logging" system currently used by the ExecutionEngine is based on the Eclipse messaging system implementation provided by Kermeta. Each plug-in has its own logger and associated console (see Activator.java in plugins execution.engine for example) and this is what is used to debug/log what is happening in the Engine.

Backends are observers registered to the engine (through the EngineManager) and are meant to display runtime information during execution - typically as a model animator for example.

It would be interesting to unify these two aspects by removing the current logging of the engine, and replacing it with notifications to the observers of the Engine. This way, logging could be done through the Backend system which would make for a better design overall. Also, future development should include the possibility of choosing the Backends and Frontends in the launch configuration and thus effectively we would have a clean way to launch the engine in debug mode.

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.

from https://gforge.inria.fr/tracker/index.php?func=detail&aid=18983&group_id=4645&atid=13870

That could be nice to have the possibility, in a run configuration, to specify the number of steps to execute...

from https://gforge.inria.fr/tracker/index.php?func=detail&aid=20007&group_id=4645&atid=13885

The new Multidimensional timeline needs JavaFX that isn't bundled in OpenJDK,

this leads to a view crash. We need to cleanly catch this and report the installation issue to the user so he may either install javaFX or Oracle JDK

from Add the possibility to set default addon based on the selected engine

In the launchconfiguration, currently addons are selected by default or not based on a single property in the addon definition.
It seems that this default value should be set depending on the engine that is used.
We can imagine that we can unse a kind of pattern matching based on the engine name. so the designer of an addon will be able to declare if his addon is intended to be used by default with a specific engine or not.

Hi.

I am trying to run another tutorial (SigPML: http://gemoc.github.io/gemoc-studio/publish/tutorial_sigpml/html_single/Tutorial_SigPML.html), but I noticed that the ZIP with the initial projects and even the simple files (.ecore and .odesign) that I could use to create the projects by myself are not available.
Where may I find them?

Thank you since now.

Regards,
Valdemar.

From @valdemarneto on February 17, 2016 12:33

Hi.

I am starting a new project of concurrent language.
I defined by language using XText and extracted the Ecore model from it.
I created the XDSML file, and selected the EMF Project, the GenModel URI.
However, when I choose the GenModel URI, the project.xdsml automatically changes, and I am not able to create a K3 or MoCCML project anymore. This is what appears:

I use GEMOC 1.0 in Windows.
Why does it happen?

It looks like this happen because I defined my language based in XText and non directly from Ecore. When I try to generate the codes referent to the language, they are created in other projects, with xtext in the name instead of being created in the same project of the model.

Thank you since now.

Copied from original issue: diverse-project/k3#41

from https://gforge.inria.fr/tracker/index.php?func=detail&aid=18239&group_id=4645&atid=13870

Hi,
I'm creating an xdsml project to do an executable version of uml.
I tried the good new xdsml but there is no way to browse registered metamodel and genmodel.

It seems important to me to highlight the possibility of reuse. I think it can be forced in the plugin.xml but getting it in the xdsml sheet would avoid problems...

workaround : import the plugin in the workspace so they are visible to the language designer.
file > Impor... > Plug-ins and Fragment > select the plugin you wish to reuse > import as Projects with source folder

from https://gforge.inria.fr/tracker/index.php?func=detail&aid=20037&group_id=4645&atid=13870

when using the Create new Domain model project the initial value of the field Package name is the last part of the project.
typically for org.company.my_language.model this will be "model"
it would be smarter to ignore "model" and use "my_language" as default value

from https://gforge.inria.fr/tracker/index.php?func=detail&aid=19690&group_id=4645&atid=13870

In the current Studio, the model must NOT be in a Sirius Modelling project due to the session management. (because of the need to close the edition session and replace it by an animation session + because of the presence of model copies in the gemoc-gen folder that store previous executions traces)

As a consequence, the creation of model is not straightforward.
We need to define a way to simplify the model creation in this context.

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: #45

from https://gforge.inria.fr/tracker/index.php?func=detail&aid=18216&group_id=4645&atid=13870

good pratice when creating a new xdsml project implies to have an activator offring some basic services (like log)

template may look like the one from SigPM (ie. inherits from GemocUIPlugin

When some componetn doesn't install correctly due to missing pre-installed feature, the message doesn't contains any useful information.

java.lang.RuntimeException: Operation details
	at org.eclipse.amalgam.discovery.ui.common.internal.PrepareInstallProfileJob.resolve(PrepareInstallProfileJob.java:143)
	at org.eclipse.amalgam.discovery.ui.common.internal.PrepareInstallProfileJob.run(PrepareInstallProfileJob.java:104)
	at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:119)

that was the case for xmof (see bug #39 ) and is currently the case when installing uml designer.

we need to find a way to capture the resolve problem and report it to the user

From @awortmann on March 14, 2017 15:23

when updating the manifest, melange generates a package export-package entry on a single line, this is fine for small projects, but creates invalid manifest files when there are a lot exported packages ...

Copied from original issue: diverse-project/melange#71

When using the New GEMOC Sequential (or Concurrent) Language project, the templates forces to have an ecore file string.
The process should allow to create the ecore later.

As a workaround one can enter a string, but in this case another bug occurs: on each character, the cursor moves to the begining of the string and thus the string is written reversed

Hi Gemoc Team,

I have installed the following examples from last version of Gemoc studio : 2.2.1 SNAPSHOT 2016-11-09 21:44 and I get errors after installing them:

• GEMOC operator for TFSM and SigPML Languages (Coordination)
• GEMOC SigPML Language (Concurrent)
• GEMOC TFSM Language (concurrent)

In hope to correct these difficulties, I have executed the commands « Clean All » and « Generate All » on files:

• Main.melange of org.gemoc.sample.sigpml package
• Main.melange of org.gemoc.sample.tfsm.concurrent

As I am a newcomer to Gemoc, I probably missed something but it difficult to learn how it works without functional examples.

Your help is therefore welcome!

Renan

——
The errors are:

Description	Resource	Path	Location	Type
org.gemoc.sample.tfsm.concurrent.k3dsa.aspect.EvaluateGuardAspect cannot be resolved to a type.	Main.melange	/org.gemoc.sample.tfsm.concurrent/src/org/gemoc/sample/tfsm/concurrent	line: 23 /org.gemoc.sample.tfsm.concurrent/src/org/gemoc/sample/tfsm/concurrent/Main.melange	Melange Problem
org.gemoc.sample.tfsm.concurrent.k3dsa.aspect.EventGuardAspect cannot be resolved to a type.	Main.melange	/org.gemoc.sample.tfsm.concurrent/src/org/gemoc/sample/tfsm/concurrent	line: 19 /org.gemoc.sample.tfsm.concurrent/src/org/gemoc/sample/tfsm/concurrent/Main.melange	Melange Problem
org.gemoc.sample.tfsm.concurrent.k3dsa.aspect.FSMClockAspect cannot be resolved to a type.	Main.melange	/org.gemoc.sample.tfsm.concurrent/src/org/gemoc/sample/tfsm/concurrent	line: 21 /org.gemoc.sample.tfsm.concurrent/src/org/gemoc/sample/tfsm/concurrent/Main.melange	Melange Problem
org.gemoc.sample.tfsm.concurrent.k3dsa.aspect.FSMEventAspect cannot be resolved to a type.	Main.melange	/org.gemoc.sample.tfsm.concurrent/src/org/gemoc/sample/tfsm/concurrent	line: 20 /org.gemoc.sample.tfsm.concurrent/src/org/gemoc/sample/tfsm/concurrent/Main.melange	Melange Problem
org.gemoc.sample.tfsm.concurrent.k3dsa.aspect.GuardAspect cannot be resolved to a type.	Main.melange	/org.gemoc.sample.tfsm.concurrent/src/org/gemoc/sample/tfsm/concurrent	line: 17 /org.gemoc.sample.tfsm.concurrent/src/org/gemoc/sample/tfsm/concurrent/Main.melange	Melange Problem
org.gemoc.sample.tfsm.concurrent.k3dsa.aspect.NamedElementAspect cannot be resolved to a type.	Main.melange	/org.gemoc.sample.tfsm.concurrent/src/org/gemoc/sample/tfsm/concurrent	line: 16 /org.gemoc.sample.tfsm.concurrent/src/org/gemoc/sample/tfsm/concurrent/Main.melange	Melange Problem
org.gemoc.sample.tfsm.concurrent.k3dsa.aspect.StateAspect cannot be resolved to a type.	Main.melange	/org.gemoc.sample.tfsm.concurrent/src/org/gemoc/sample/tfsm/concurrent	line: 14 /org.gemoc.sample.tfsm.concurrent/src/org/gemoc/sample/tfsm/concurrent/Main.melange	Melange Problem
org.gemoc.sample.tfsm.concurrent.k3dsa.aspect.TemporalGuardAspect cannot be resolved to a type.	Main.melange	/org.gemoc.sample.tfsm.concurrent/src/org/gemoc/sample/tfsm/concurrent	line: 18 /org.gemoc.sample.tfsm.concurrent/src/org/gemoc/sample/tfsm/concurrent/Main.melange	Melange Problem
org.gemoc.sample.tfsm.concurrent.k3dsa.aspect.TFSMAspect cannot be resolved to a type.	Main.melange	/org.gemoc.sample.tfsm.concurrent/src/org/gemoc/sample/tfsm/concurrent	line: 13 /org.gemoc.sample.tfsm.concurrent/src/org/gemoc/sample/tfsm/concurrent/Main.melange	Melange Problem
org.gemoc.sample.tfsm.concurrent.k3dsa.aspect.TimedSystemAspect cannot be resolved to a type.	Main.melange	/org.gemoc.sample.tfsm.concurrent/src/org/gemoc/sample/tfsm/concurrent	line: 22 /org.gemoc.sample.tfsm.concurrent/src/org/gemoc/sample/tfsm/concurrent/Main.melange	Melange Problem
org.gemoc.sample.tfsm.concurrent.k3dsa.aspect.TransitionAspect cannot be resolved to a type.	Main.melange	/org.gemoc.sample.tfsm.concurrent/src/org/gemoc/sample/tfsm/concurrent	line: 15 /org.gemoc.sample.tfsm.concurrent/src/org/gemoc/sample/tfsm/concurrent/Main.melange	Melange Problem
Package 'org.gemoc.sample.tfsm.concurrent.xtfsm.aspects' does not exist in this plug-in	MANIFEST.MF	/org.gemoc.sample.tfsm.concurrent.xtfsm/META-INF	line 15	Plug-in Problem
Unresolved '' 'Agent'	SigPML.ecl	/org.gemoc.sample.sigpml.moc.dse/MoCApplication	line: 87 /org.gemoc.sample.sigpml.moc.dse/MoCApplication/SigPML.ecl	Xtext Check (fast)
Unresolved '' 'Agent'	SigPML.ecl	/org.gemoc.sample.sigpml.moc.dse/MoCApplication	line: 9 /org.gemoc.sample.sigpml.moc.dse/MoCApplication/SigPML.ecl	Xtext Check (fast)
Unresolved '' 'HWComputationalResource'	SigPML.ecl	/org.gemoc.sample.sigpml.moc.dse/MoCApplication	line: 27 /org.gemoc.sample.sigpml.moc.dse/MoCApplication/SigPML.ecl	Xtext Check (fast)
Unresolved '' 'HWComputationalResource'	SigPML.ecl	/org.gemoc.sample.sigpml.moc.dse/MoCApplication	line: 96 /org.gemoc.sample.sigpml.moc.dse/MoCApplication/SigPML.ecl	Xtext Check (fast)
Unresolved '' 'HWStorageResource'	SigPML.ecl	/org.gemoc.sample.sigpml.moc.dse/MoCApplication	line: 117 /org.gemoc.sample.sigpml.moc.dse/MoCApplication/SigPML.ecl	Xtext Check (fast)
Unresolved '' 'HWStorageResource'	SigPML.ecl	/org.gemoc.sample.sigpml.moc.dse/MoCApplication	line: 31 /org.gemoc.sample.sigpml.moc.dse/MoCApplication/SigPML.ecl	Xtext Check (fast)
Unresolved '' 'InputPort'	SigPML.ecl	/org.gemoc.sample.sigpml.moc.dse/MoCApplication	line: 14 /org.gemoc.sample.sigpml.moc.dse/MoCApplication/SigPML.ecl	Xtext Check (fast)
Unresolved '' 'InputPort'	SigPML.ecl	/org.gemoc.sample.sigpml.moc.dse/MoCApplication	line: 59 /org.gemoc.sample.sigpml.moc.dse/MoCApplication/SigPML.ecl	Xtext Check (fast)
Unresolved '' 'OutputPort'	SigPML.ecl	/org.gemoc.sample.sigpml.moc.dse/MoCApplication	line: 18 /org.gemoc.sample.sigpml.moc.dse/MoCApplication/SigPML.ecl	Xtext Check (fast)
Unresolved '' 'OutputPort'	SigPML.ecl	/org.gemoc.sample.sigpml.moc.dse/MoCApplication	line: 74 /org.gemoc.sample.sigpml.moc.dse/MoCApplication/SigPML.ecl	Xtext Check (fast)
Unresolved '' 'Place'	SigPML.ecl	/org.gemoc.sample.sigpml.moc.dse/MoCApplication	line: 21 /org.gemoc.sample.sigpml.moc.dse/MoCApplication/SigPML.ecl	Xtext Check (fast)
Unresolved '' 'Place'	SigPML.ecl	/org.gemoc.sample.sigpml.moc.dse/MoCApplication	line: 35 /org.gemoc.sample.sigpml.moc.dse/MoCApplication/SigPML.ecl	Xtext Check (fast)
Unresolved '' 'sigpml'	SigPML.ecl	/org.gemoc.sample.sigpml.moc.dse/MoCApplication	line: 7 /org.gemoc.sample.sigpml.moc.dse/MoCApplication/SigPML.ecl	Xtext Check (fast)
Unresolved import 'http://org.gemoc.sample.sigpml.xsigpml/sigpml/' : org.gemoc.sample.sigpml.xsigpml	SigPML.ecl	/org.gemoc.sample.sigpml.moc.dse/MoCApplication	line: 1 /org.gemoc.sample.sigpml.moc.dse/MoCApplication/SigPML.ecl	Xtext Check (fast)
Unresolved Type 'Place'	SigPML.ecl	/org.gemoc.sample.sigpml.moc.dse/MoCApplication	line: 71 /org.gemoc.sample.sigpml.moc.dse/MoCApplication/SigPML.ecl	Xtext Check (fast)
Unresolved Type 'Place'	SigPML.ecl	/org.gemoc.sample.sigpml.moc.dse/MoCApplication	line: 84 /org.gemoc.sample.sigpml.moc.dse/MoCApplication/SigPML.ecl	Xtext Check (fast)

from https://gforge.inria.fr/tracker/index.php?func=detail&aid=20042&group_id=4645&atid=13870
and from https://gforge.inria.fr/tracker/index.php?func=detail&aid=20043&group_id=4645&atid=13870

Currently the completion allows to create the domain model project and DSA project only if there is no keywords.
once "syntax" is typed, the completion only proposes to select an ecore file (it doesn't propose to create it anymore)
once "with" is typed, the completion only propose to select an aspect or (it doesn't propose to create it anymore)

from https://gforge.inria.fr/tracker/index.php?func=detail&aid=19684&group_id=4645&atid=13870

In the launchconfiguration, when selecting a model and a language, it should be possible to show an error if these elements aren't compatible.
Basic approach, if the file extension of the model is not recognized for the given language.

In concurrent mode, in the "Stimuli manager" view, there is the possibility to add a breakpoint on an MSE. This break will never happen.

With the current code, this will never work for two reasons:

• This stores a breakpoint for the timesquare object "fr.inria.aoste.timesquare.ecl.feedback.feedback.impl.ModelSpecificEventImpl", and not for the corresponding GEMOC object "fr.inria.diverse.trace.commons.model.trace.MSE"
• The concurrent debugger only calls shouldBreak on the starting Step, and never on the MSEOccurrence that may trigger this step

To fix this problem, we must find the underlying MSE when creating breakpoints, and we must fix how breakpoints are checked in concurrent mode.

Using the latest studio (12-Apr-2017 17:45), when using the components discovery to install xMOF, I have an error saying "Problems occured" and the following exception in the log:

java.lang.RuntimeException: Operation details
	at org.eclipse.amalgam.discovery.ui.common.internal.PrepareInstallProfileJob.resolve(PrepareInstallProfileJob.java:143)
	at org.eclipse.amalgam.discovery.ui.common.internal.PrepareInstallProfileJob.run(PrepareInstallProfileJob.java:104)
	at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:119)

Screenshot:

I was not sure to put the issue on the moliz.gemoc repo or here, but since the error happens before having installed xMOF, I thought here was better :)

from https://gforge.inria.fr/tracker/index.php?func=detail&aid=19822&group_id=4645&atid=13870

In case of model with xText representations, the selection of the current instruction should be able to highlight the EObject in hte xtext editor

there are some example that aren't distributed (old version or version in preparation)
they should be removed from the repo (and saved in another repo) before submitting the code for IP review

this is the case for TFSM_PlainK3 and MiniFSM

Hi Gemoc team,
Sorry to bother you again. I began to implement a toy model by myself now. I added ED and EF to my meta-model by simply adding attributes and an operation to the classes, regenerated code, edit and editor then generate DSA project. However xtend file compilation gave me a lot of errors and I couldn't figure out why. Since I'm new to this area I'm not quite sure if I extended my AS with ED and EF correctly. Is there anything special about that? Or do you have anything in mind about what caused the problem? Thank you.

Error messages:

It gave null exception on the first line of the xtend file which specify package. It also couldn't resolve all the classNames and aspectized classes

in order to simplify IP verification and future images modifications, we should gather all images sources in a folder such as "artwork" or resources

Currently I'm implementing a counter-like model by myself. In the model a father node has an operation called GoStudy(). When the operation is called, the score attribute of child nodes would be increased by 1. I'm following the instructions in MarkedGraph tutorial step by step. The problem occurred when launching the debug configuration as step 5.5 in MarkedGraph tutorial. A window popped up and giving the following error message:
'Launching run Test' has encountered a problem. Error occurred when starting execution engine: null (see inner exception).
Error occured when starting execution engine: null (see inner exception).
java.lang.NullPointerException

It doesn't give any information about where the bug locates. It seems like some of the inputs to the execution engine is missing.

In the Console of modeling workbench these messages are given before the error appeared:
About to initialize and run the GEMOC Execution Engine...
Input resources:
platform:/resource/Test/My.family
platform:/resource/Test/gemoc-gen/My.timemodel
platform:/plugin/fr.inria.aoste.timesquare.ccslkernel.model/ccsllibrary/kernel.ccslLib
platform:/plugin/fr.inria.aoste.timesquare.ccslkernel.model/ccsllibrary/CCSL.ccslLib

Since I'm using my own model, I'm not sure if it's because there is any logical inperfection in the model itself or in the dsa/dse definition that caused this error. Could you give me some suggestions on what could be the problem? Thank you.