Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
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 Go to next message
Kirsten M. Z. is currently offline Kirsten M. Z.Friend
Messages: 131
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 Smile

@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 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4153
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 Go to previous messageGo to next message
Kirsten M. Z. is currently offline Kirsten M. Z.Friend
Messages: 131
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 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4153
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.
Re: Using "OCL" instead of "OCL/Pivot" within Oc [message #1045604 is a reply to message #1045577] Sat, 20 April 2013 14:42 Go to previous messageGo to next message
Kirsten M. Z. is currently offline Kirsten M. Z.Friend
Messages: 131
Registered: July 2010
Senior Member
> If you can get the trace raise a Bugzilla. Obviously I don't have tome
> to pursue a well-I-think-it-might-be.

Obviously not, just wanted to give some background information. I will open, if I encounter the problem again, of course.

> But the Pivot evaluator comes with an OCL to Java generator, that avoids
> most of the Overheads

The application shall allow typing simple OCL expressions. This is why generating code is not an option Wink

> I did most of the work to add an OCLinEcore editor preference feature,
> but never got round to completing it.

Is there a Bugzilla I can follow?
Re: Using "OCL" instead of "OCL/Pivot&amp [message #1053722 is a reply to message #1045604] Tue, 07 May 2013 11:36 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4153
Registered: July 2009
Senior Member
On 20/04/2013 15:42, Kirsten M. Z. wrote:
>> I did most of the work to add an OCLinEcore editor preference
>> feature, but never got round to completing it.
>
> Is there a Bugzilla I can follow?
It was almost exactly this time a year ago and I decided that the
preference feature wasn't really the right solution.

In M7, the OCLinEcore editor no longer imposes the Pivot delegate URI
whenever saving, instead it will continue to use a consistent delegate
URI from the input file, defaulting to a preference only if confused.

Within the editor there is a Set Export Delegate URI to override the
URI deduced from the input/preference, so you can change the URI to LPG
on a first edit of each *.ecore and then expect it to persist thereafter.

Unfortunately I don't have time to sort out how to make the menu options
show the current URI as a radio button state.

Regards

Ed Willink
Previous Topic:Help requested for closure constraint.
Next Topic:[Announce] Eclipse OCL 4.1.0 (Kepler) M7 is now available.
Goto Forum:
  


Current Time: Mon Nov 24 18:09:37 GMT 2014

Powered by FUDForum. Page generated in 0.03813 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software