Home » Modeling » OCL » Using "OCL" instead of "OCL/Pivot" within OclInEcore editor
| Using "OCL" instead of "OCL/Pivot" within OclInEcore editor [message #1045259] |
Sat, 20 April 2013 01:38  |
 Kirsten M. Z.
Messages: 132
Registered: July 2010 |
Senior Member |
|
|
Hi @all,
after starting with the pivot model, we have to use the non-Pivot model, i.e. using "http://www.eclipse.org/emf/2002/Ecore/OCL" instead of "http://www.eclipse.org/emf/2002/Ecore/OCL/Pivot".
Unfortunately, the OclInEcore Editor automatically uses the pivot model. Is there a way to switch back? Using the OclInEcore editor is really comfortable, and we don't want to miss it 
@Background: We encountered some weird operation return value bugs (InvalidValueException) using pivot and 'body'. No problems without pivot. However, we did not investigate any further, because we cannot use pivot because of other technical reasons anyway. The library is too complex. If you ask why such a library is too complex in the 21th century, you haven't heard about the Google guys who limited the Dalvik VM to 65536 methods per application.
[Updated on: Sat, 20 April 2013 01:39] Report message to a moderator |
|
|
| Re: Using "OCL" instead of "OCL/Pivot" within OclInEcore editor [message #1045358 is a reply to message #1045259] |
Sat, 20 April 2013 05:38  |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
I did most of the work to add an OCLinEcore editor preference feature,
but never got round to completing it.
I'm afraid I have very limited sympathy for users who can't cut and
paste a stack traces demonstrating their wierd InvalidValueExceptions.
As for 65536 methods in a library, the OCL Standard Library has one
method per function and is probably far too small, so I've no idea what
you are complaining about.
Regards
Ed
On 20/04/2013 02:38, Kirsten M. Z. wrote:
> Hi @all,
>
> after starting with the pivot model, we have to use use the non-Pivot
> model no, i.e. using "http://www.eclipse.org/emf/2002/Ecore/OCL"
> instead of "http://www.eclipse.org/emf/2002/Ecore/OCL/Pivot".
>
> Unfortunately, the OclInEcore Editor automatically uses the pivot
> model. Is there a way to switch back? Using the OclInEcore editor is
> really comfortable, and we don't want to miss it :)
>
> @Background: We encountered some weird operation return value bugs
> (InvalidValueException) using pivot and 'body'. No problems without
> pivot. However, we did not investigate any further, because we cannot
> use pivot because of other technical reasons anyway. The library is
> too complex. If you ask why such a library is too complex in the 21th
> century, you haven't heard about the Google guys who limited the
> Dalvik VM to 65536 methods per application.
|
|
|
| Re: Using "OCL" instead of "OCL/Pivot" within OclInEcore editor [message #1045467 is a reply to message #1045358] |
Sat, 20 April 2013 09:34 |
Kirsten M. Z.
Messages: 132
Registered: July 2010 |
Senior Member |
|
|
Hi Ed,
> I'm afraid I have very limited sympathy for users who can't cut and
> paste a stack traces demonstrating their wierd InvalidValueExceptions.
Sorry, it was not my intention to upset you. The problem is that I cannot reproduce the "weird" exception. I still had my 'debug breakpoint' with 'InvalidValueException', and before posting I tried reverting all my changes I did for using 'OCL' instead of 'OCL/Pivot'. I have absolutely no idea which unknown variable is different now, so it works. And yes, I am absolutely sure that the OCL body did not change a bit, the ecore model did not change (except cutting 'Pivot') and I generated the code right before I got the exception. Therefore, I called the problem 'weird'. I stopped investigating then (as I said), because we cannot use pivot anyways.
What I can recall from my memory:
First a code snippet which has the same structure as the model we use.
class System
{
operation getData(n : String) : ClassBase
{
body: someData->any(metaInfo.name = n);
}
property someData: ClassBase[*] { composes };
}
abstract class ClassBase
{
property metaInfo : MetaInfo;
}
class ClassConcrete extends ClassBase
{
}
class MetaInfo
{
attribute name : String;
}
Calling 'getData' resulted in the exception then. From my memory: internally he validated the operation and checked using a 'conformsTo' method. There he checked if Metaclass(ClassBase) conforms to some collection type, which was obviously not the case => error: return type is incorrect.
> As for 65536 methods in a library, the OCL Standard Library has one
> method per function and is probably far too small, so I've no idea what
> you are complaining about.
No, I did not want to complain, sorry! The library by itself is fine, and probably it was not too obvious that my words 'too complex' were ironic. You should know that next to OCL there are also other dependencies (of course, EMF, and other stuff). After optimization there are only about 15.000 methods left (without OCL or own code!). Then, OCL must be included. In a first naive try we included everything which sounded necessary, including the 'OCLinEcore' libraries. Even without this (and without knowing it better), there is the dependency of the EssentialOCL library. Then Xtext, then the stuff Xtext relies on... google.inject, aopalliance, CGLib, etc, etc, etc. 65536 is nothing! Nothing! Our conclusion was: ok, maybe we can optimize, maybe we can drop unnecessary dependencies. However: the basic OCL library is required anyways, and pivot is not a hard requirement for our OCL constraints. Therefore, dropping pivot and using non-pivot OCL was our first idea.
[Updated on: Sat, 20 April 2013 09:38] Report message to a moderator |
|
|
| Re: Using "OCL" instead of "OCL/Pivot" within Oc [message #1045577 is a reply to message #1045467] |
Sat, 20 April 2013 13:47 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
If you can get the trace raise a Bugzilla. Obviously I don't have tome
to pursue a well-I-think-it-might-be.
Yes, the total size is huge.
But the Pivot evaluator comes with an OCL to Java generator, that avoids
most of the overheads; all the run-time parsing, and a lot of
interpreted dispatch overheads. You need only the ocl.examples.domain
and ocl.examples.library plugins, unless you do some reflection
(oclType(), oclIsKindOf(), ...) in which case you need
ocl.examples.pivot too, but you do not need any ocl.examples.xtext.*.
(The validation code in the editor is auto-generated from Pivot.ocl!).
The aim is to have UML 2.5 support in Luna auto-generated from the OMG
specification, rather than transliteration.
In the pipeline (there is a work-in-progress plugin) is an Xtext to LPG
grammar-to-grammar transformation so that we should eventually be able
to compile with much smaller (ten-times) grammar tables.
Regards
Ed
On 20/04/2013 10:34, Kirsten M. Z. wrote:
> Hi Ed,
>
>> I'm afraid I have very limited sympathy for users who can't cut and
>> paste a stack traces demonstrating their wierd InvalidValueExceptions.
>
> Sorry, it was not my intention to upset you. The problem is that I
> cannot reproduce the "weird" exception. I still had my 'debug
> breakpoint' with 'InvalidValueException', and before posting I tried
> reverting all my changes I did for using 'OCL' instead of 'OCL/Pivot'.
> I have absolutely no idea which unknown variable is different now, so
> it works. And yes, I am absolutely sure that the OCL body did not
> change a bit, the ecore model did not Change (except cutting 'Pivot')
> and I generated the code right before I got the exception. Therefore,
> I called the problem 'weird'. I stopped investigating then (as I
> said), because we cannot use pivot anyways.
>
> What I can recall from my memory:
>
> First a code snippet which has the same structure as the model we use.
>
>
> class System
> {
> operation getData(n : String) : ClassBase
> {
> body: someData->any(metaInfo.name = n);
> }
> property someData: ClassBase[*] { composes };
> }
> abstract class ClassBase
> {
> property metaInfo : MetaInfo;
> }
> class ClassConcrete extends ClassBase
> {
> }
> class MetaInfo
> {
> attribute name : String;
> }
>
>
> Calling 'getData' resulted in the exception then. From my memory:
> internally he validated the operation and checked using a 'conformsTo'
> method. There he checked if Metaclass(ClassBase) conforms to some
> collection type, which was obviously not the case => error: return
> type is incorrect.
>
>> As for 65536 methods in a library, the OCL Standard Library has one
>> method per function and is probably far too small, so I've no idea
>> what you are complaining about.
>
> No, I did not want to complain, sorry! The library by itself is fine,
> and probably it was not too obvious that my word 'too complex' were
> ironic. You should know that next to OCL there are also other
> dependencies (of course, EMF, and other stuff). After optimization
> there are only about 15.000 methods left (without OCL or own code!).
> Then, OCL must be included. In a first naive try we included
> everything which sounded necessary, including the 'OCLinEcore'
> libraries. Event without this (and without knowing it better), there
> is the dependency of the EssentialOCL library. Then Xtext, then the
> stuff Xtext relies on... google.inject, aopalliance, CGLib, etc, etc,
> etc. 65536 is nothing! Nothing! Our conclusion was: ok, maybe we can
> optimize, maybe we can drop unnecessaey dependencies. However: the
> basic OCL library is required anyways, and pivot is not a hard
> requirement for our OCL constraints. Therefore, dropping pivot and
> using non-pivot OCL was our first idea.
|
|
| | |
Goto Forum:
Current Time: Fri Apr 26 00:20:21 GMT 2024
Powered by FUDForum. Page generated in 0.03577 seconds |
] 
Search
Help
Register
Login
Home
