Open eclipse-qvt-oml-bot opened 6 days ago
By Ed Willink on Jun 06, 2012 01:22
In Juno, MDT OCL introduces Workspace/Project preference pages for a number of options.
This functionality could be cloned to provide QVTo options. Too late for Juno now.
By Christopher Gerking on Nov 14, 2012 06:31
Using workspace-based preference pages, the problem remains for deployed transformations. Maybe a global option (affecting all workspace/deployed transformations) is a better solution in the first place?
By Ed Willink on Feb 05, 2013 06:00
(In reply to comment #0)
71 public static final int MAX_STACK_DEPTH = 300;
This is an arbitrary constant used in just one place:
static void EvaluationUtil.checkCurrentStackDepth(QvtOperationalEvaluationEnv env) throws QvtStackOverFlowError {
to protect against infinite recursions.
This constant could easily be moved to a QvtOperationalEvaluationEnv option since QvtOperationalEvaluationEnv inherits the ability to have configurable option from AbstractEvaluationEnvironment.
A user can then set a better value programmatically.
Since a user has hit 300, perhaps we should change the default to 1000.
The OCL UI preference pages operate on options, so cloning an OCL UI plugin would provide an interactive capability.
[Examine org.eclipse.ocl.options.EvaluationOptions.DYNAMIC_DISPATCH to see how OCL supports options.]
By Christopher Gerking on Apr 23, 2014 11:55
Any chance to get this blocker fixed for Luna?
By Ed Willink on Apr 23, 2014 12:36
(In reply to Ed Willink from comment #3)
(In reply to comment #0)
71 public static final int MAX_STACK_DEPTH = 300;
This is an arbitrary constant used in just one place:
static void
EvaluationUtil.checkCurrentStackDepth(QvtOperationalEvaluationEnv env) throws QvtStackOverFlowError {
to protect against infinite recursions.
This constant could easily be moved to a QvtOperationalEvaluationEnv option since QvtOperationalEvaluationEnv inherits the ability to have configurable option from AbstractEvaluationEnvironment.
A user can then set a better value programmatically.
This seems really easy.
Since a user has hit 300, perhaps we should change the default to 1000.
Still seems like a good idea.
The OCL UI preference pages operate on options, so cloning an OCL UI plugin would provide an interactive capability.
[Examine org.eclipse.ocl.options.EvaluationOptions.DYNAMIC_DISPATCH to see how OCL supports options.]
This is quite a bit of work.
I recommend you do at least the first two of the ideas above. I'm afraid I don't have time before Luna.
By Sergey Boyko on May 06, 2014 07:37
Patch was committed which turns MAX_STACK_DEPTH into configurable setting.\ Patch only allows to externally control this setting with org.eclipse.m2m.qvt.oml.ExecutionContext interface when running transformation via TransformationExecutor. UI integration TBD.
Pushed to master for M7.\ commit d7102d08a42671bcc289267f0965b1403bedd5b2
| --- | --- | | Bugzilla Link | 370098 | | Status | NEW | | Importance | P3 critical | | Reported | Jan 30, 2012 03:53 EDT | | Modified | May 06, 2014 07:37 EDT | | Reporter | Dennis Hendriks |
Description
Build Identifier: Build id: 20110916-0149, Version: Indigo Service Release 1
See http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.m2m/org.eclipse.m2m.qvt.oml/plugins/org.eclipse.m2m.qvt.oml/src/org/eclipse/m2m/internal/qvt/oml/ast/env/QvtOperationalEvaluationEnv.java?view=markup&revision=1.47&root=Modeling_Project
The QvtOperationalEvaluationEnv has the following code:
70 // TODO - make this optional settings for execution\ 71 public static final int MAX_STACK_DEPTH = 300;
I've run into several maximum stack depth exceeded exceptions already. Often it is possible to change the input model or the QVTo transformation to stay just below this limit, but the fundamental issue remains. And sometimes the input has simply too much depth. I think it is time to fix this TODO...
Reproducible: Always
Steps to Reproduce:\ See details...