Open eclipse-viatra-bot opened 6 months ago
By Zoltan Ujhelyi on Jan 29, 2016 17:46
Just two additional concerns:
By Andras Szabolcs Nagy on Jan 30, 2016 02:40
It's nice to hear!\ I'm sure you have great ideas and I'll follow your work on this subject.\ Until then, I postpone this bug.
By Gabor Bergmann on Jan 30, 2016 12:20
We might want to look into coroutine-style programming to avoid spinning up extra threads in case of solution 2.
By Andras Szabolcs Nagy on Feb 01, 2016 05:07
Coroutine-style programming is also occurred to me but Java doesn't support it in an easy way (i.e. yield return), that's why I suggested the extra threads which of course I also don't like.
But as I searched for it, you are right, there could be ways to use it. Related stackoverflow question: http://stackoverflow.com/questions/2846664/implementing-coroutines-in-java
By Zoltan Ujhelyi on Mar 17, 2016 08:38
Added new tickets to 1.3
By Zoltan Ujhelyi on May 26, 2016 08:34
Moved to 1.4
By Andras Szabolcs Nagy on Aug 02, 2016 05:02
Postponing this feature.
| --- | --- | | Bugzilla Link | 486802 | | Status | NEW | | Importance | P3 normal | | Reported | Jan 29, 2016 05:31 EDT | | Modified | Aug 02, 2016 05:02 EDT | | Version | 0.9.0 | | Depends on | 488783 | | Reporter | Andras Szabolcs Nagy |
Description
Recently a debugger for VIATRA transformations has been contributed: it would be nice to integrate it with the DSE framework.
However, the current DSE implementation uses only a RuleEngine without custom ConflictResolver, ConflictSet or Executor and fires activations on its own behalf, which leaves the AdaptableExecutor unusable.
Based on my investigations, there are five solutions:
1) Exploration strategies are defined through a ConflictSet and the (Adaptable)Executor is settable through the main API.
My main concern about this solution is that it requires the strategy API to use "pull" like behavior - like overriding getNextActivation(). Previously, the strategy API was constructed in a similar way that made complex strategies hard to write, understand, optimize and debug. Hence, I've started to change the Strategy API to a "push" like architecture where the strategy has maximal control, which has made strategies easier to write, understand, optimize and debug.
2) If a DSEConflictSet.getNextActivation() could call the strategy asynchronously it would allow the "push" like strategy API. But this needs an extra thread for each exploration thread, which may impact performance.
3) The main idea in the new debug framework is the ITransforamtionAdapter (listener) interface. This could be easily integrated into the DSE component.
However, DSE is a bit more than a model transformation, a debugger needs adapters for backtracking, calculating objectives/global constraints, storing solutions, optionally strategy specific events and may be more considering the multi-threaded strategies.
4) Like solution 3) but using an interface derived from ITransforamtionAdapter with more funcionality.
5) Completely DSE specific adapters could be an option too. ITransforamtionAdapter may be still reused.
In my opinion, solution 4) and 5) are the best options.