Reference implementation for Famix 3.0? - Moose-dev

Tudor Girba

9 Oct 9 Oct

2:53 p.m.

Hi, Sorry for the trouble. FAMIX 3.0 is a construction site and the information is not consistent. The website shows the beta 14 version which is about half a year old. The current and running one can be found in the Famix-Specification package in the http://www.squeaksource.com/Moose Squeak repository. I will try to put a new image and the specification online in the following days. Cheers, Doru On Oct 9, 2008, at 12:10 PM, Simon Denier wrote:

...

I'm confused Where is the reference implementation for Famix 3.0 right now? Because when I look at those documents http://moose.unibe.ch/docs/famix/famix3.0?_s=qCdqiYvltMRJXWPd&_k=KPeddY… Famix 3.0 beta 14 it does not match with what I found in the Squeak package. Namely, there is no incomingInvocations in the FAMIXEntity class. Also some methods such as Access>>isRead are not implemented. However, when I look at the generated code with Fame for Java and the mse file included (FAMIX30.fm3.mse), the attribute incomingInvocations is defined. However (another problem?), it is declared as an opposite to Invocation>>candidates, but this one declares BehaviouralEntity>>incomingInvocations as the opposite. So, I'm really confused. -- Simon Denier, PhD Postdoc, Ptidej Team DIRO, Université de Montréal _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com www.tudorgirba.com/blog "To lead is not to demand things, it is to make them happen."

Reply

Tudor Girba

5:48 p.m.

Hi Stef, We have it :). It is in the Famix-Specification package. I will post it on the website as soon as I get around to do that. Cheers, Doru On Oct 9, 2008, at 3:01 PM, Stéphane Ducasse wrote:

...

doru could we have the mse version of famix30? Stef On Oct 9, 2008, at 2:53 PM, Tudor Girba wrote:

Hi, Sorry for the trouble. FAMIX 3.0 is a construction site and the information is not consistent. The website shows the beta 14 version which is about half a year old. The current and running one can be found in the Famix-Specification package in the http://www.squeaksource.com/Moose Squeak repository. I will try to put a new image and the specification online in the following days. Cheers, Doru On Oct 9, 2008, at 12:10 PM, Simon Denier wrote:

I'm confused Where is the reference implementation for Famix 3.0 right now? Because when I look at those documents http://moose.unibe.ch/docs/famix/famix3.0?_s=qCdqiYvltMRJXWPd&_k=KPeddY… Famix 3.0 beta 14 it does not match with what I found in the Squeak package. Namely, there is no incomingInvocations in the FAMIXEntity class. Also some methods such as Access>>isRead are not implemented. However, when I look at the generated code with Fame for Java and the mse file included (FAMIX30.fm3.mse), the attribute incomingInvocations is defined. However (another problem?), it is declared as an opposite to Invocation>>candidates, but this one declares BehaviouralEntity>>incomingInvocations as the opposite. So, I'm really confused. -- Simon Denier, PhD Postdoc, Ptidej Team DIRO, Université de Montréal _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com www.tudorgirba.com/blog "To lead is not to demand things, it is to make them happen." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com www.tudorgirba.com/blog "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

Reply

Simon Denier

10 Oct 10 Oct

4:40 p.m.

Thanks for your clarification, it helps! Now I can compare the generated code under VW with Squeak (as well as with Fame4Java but it's another story) The code seems fine except for Association>>below as well as Access>>isRead Both are implemented with 'self shoudBeImplemented' Both are derived attributes Association>>below is the opposite attribute of Association>>above It seems obvious that isRead is derived from isWrite. there should be some code at least to update the one-to-one relationship between above<->below. did I miss something? On 9 oct. 08, at 14:53, Tudor Girba wrote:

...

Hi, Sorry for the trouble. FAMIX 3.0 is a construction site and the information is not consistent. The website shows the beta 14 version which is about half a year old. The current and running one can be found in the Famix-Specification package in the http://www.squeaksource.com/Moose Squeak repository. I will try to put a new image and the specification online in the following days. Cheers, Doru On Oct 9, 2008, at 12:10 PM, Simon Denier wrote:

I'm confused Where is the reference implementation for Famix 3.0 right now? Because when I look at those documents http://moose.unibe.ch/docs/famix/famix3.0?_s=qCdqiYvltMRJXWPd&_k=KPeddY… Famix 3.0 beta 14 it does not match with what I found in the Squeak package. Namely, there is no incomingInvocations in the FAMIXEntity class. Also some methods such as Access>>isRead are not implemented. However, when I look at the generated code with Fame for Java and the mse file included (FAMIX30.fm3.mse), the attribute incomingInvocations is defined. However (another problem?), it is declared as an opposite to Invocation>>candidates, but this one declares BehaviouralEntity>>incomingInvocations as the opposite. So, I'm really confused. -- Simon Denier, PhD Postdoc, Ptidej Team DIRO, Université de Montréal _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com www.tudorgirba.com/blog "To lead is not to demand things, it is to make them happen." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- Simon Denier, PhD Postdoc, Ptidej Team DIRO, Université de Montréal

Reply

Simon Denier

13 Oct 13 Oct

11:01 a.m.

On 12 oct. 08, at 12:12, Tudor Girba wrote:

...

No, you had it right :). The only problem is that we cannot specify these derived options in Fame. In this case it is easy because it's just a negation, but in other cases it can be more complicated.

Sorry for the cross-post, but since I guess it can be of interest for eberybody. So I understand the rationale, but the squeak code generator and the Java code generator are not consistent. - in Java some code is generated, more specifically in Famix3: - above<->below is a one-to-one relationship and the update code can be generated (as is the case in Fame Java) - isRead is implemented as a normal attribute complete with an instance variable, without any update code - but it should be a derived attribute - in squeak both are left as 'shouldBeImplemented' Actually I think that both are 50% right/50% wrong. Fame Java does it right when generating the update code for one-one relationship, but is wrong when it implements isRead - the derived property is lost and this is something which is easily overlooked - as you say it should be left as is.

...

Cheers, Doru On Oct 10, 2008, at 4:40 PM, Simon Denier wrote:

Thanks for your clarification, it helps! Now I can compare the generated code under VW with Squeak (as well as with Fame4Java but it's another story) The code seems fine except for Association>>below as well as Access>>isRead Both are implemented with 'self shoudBeImplemented' Both are derived attributes Association>>below is the opposite attribute of Association>>above It seems obvious that isRead is derived from isWrite. there should be some code at least to update the one-to-one relationship between above<->below. did I miss something? On 9 oct. 08, at 14:53, Tudor Girba wrote:

Hi, Sorry for the trouble. FAMIX 3.0 is a construction site and the information is not consistent. The website shows the beta 14 version which is about half a year old. The current and running one can be found in the Famix-Specification package in the http://www.squeaksource.com/Moose Squeak repository. I will try to put a new image and the specification online in the following days. Cheers, Doru On Oct 9, 2008, at 12:10 PM, Simon Denier wrote:

I'm confused Where is the reference implementation for Famix 3.0 right now? Because when I look at those documents http://moose.unibe.ch/docs/famix/famix3.0?_s=qCdqiYvltMRJXWPd&_k=KPeddY… Famix 3.0 beta 14 it does not match with what I found in the Squeak package. Namely, there is no incomingInvocations in the FAMIXEntity class. Also some methods such as Access>>isRead are not implemented. However, when I look at the generated code with Fame for Java and the mse file included (FAMIX30.fm3.mse), the attribute incomingInvocations is defined. However (another problem?), it is declared as an opposite to Invocation>>candidates, but this one declares BehaviouralEntity>>incomingInvocations as the opposite. So, I'm really confused. -- Simon Denier, PhD Postdoc, Ptidej Team DIRO, Université de Montréal _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com www.tudorgirba.com/blog "To lead is not to demand things, it is to make them happen." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- Simon Denier, PhD Postdoc, Ptidej Team DIRO, Université de Montréal _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com www.tudorgirba.com/blog "Beauty is where we see it." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- Simon Denier, PhD Postdoc, Ptidej Team DIRO, Université de Montréal

Reply

Simon Denier

5:31 p.m.

New subject: [Fame-dev] Re: Re: Reference implementation for Famix 3.0?

On 13 oct. 08, at 11:23, Adrian Kuhn wrote:

...

I am lost. Can you provide me a precise bug report?

Actually there is two, one for Squeak/Fame and the other for Java/ Fame. Should I post them on: http://code.google.com/p/moose-technology/issues/list Anyway, here is the first for Squeak/Fame (I will post the second on the Fame ML only, as it only concerns Fame 4 Java) Ttitle: one-to-one relationship are not implemented Description: when two properties are declared as opposite but not multivalued, and one is derived, this implies a one-to-one relationship between the two classes (or at least this is my working hypothesis :)). In particular the setter method for each of these attributes should update the opposite attribute. However, the code for the derived attribute is not generated (see example below) Note: this case is handled in Fame 4 Java but with a double recursion schema. Alternate solution: create a FMOnevalueLink which would take care of the update logic. Example: From Famix3 current specification, attributes above and below are opposite, both defined in Association, below is derived from above. Current generated code: below <MSEProperty: #below type: #FAMIXAssociation opposite: #above> <derived> ^self shoudBeImplemented below: anAssociation below set: anAssociation initialize super initialize. above := nil. (below is not initialized)

...

cheers, AA On 13 Oct 2008, at 11:01 , Simon Denier wrote:

On 12 oct. 08, at 12:12, Tudor Girba wrote:

No, you had it right :). The only problem is that we cannot specify these derived options in Fame. In this case it is easy because it's just a negation, but in other cases it can be more complicated.

Sorry for the cross-post, but since I guess it can be of interest for eberybody. So I understand the rationale, but the squeak code generator and the Java code generator are not consistent. - in Java some code is generated, more specifically in Famix3: - above<->below is a one-to-one relationship and the update code can be generated (as is the case in Fame Java) - isRead is implemented as a normal attribute complete with an instance variable, without any update code - but it should be a derived attribute - in squeak both are left as 'shouldBeImplemented' Actually I think that both are 50% right/50% wrong. Fame Java does it right when generating the update code for one-one relationship, but is wrong when it implements isRead - the derived property is lost and this is something which is easily overlooked - as you say it should be left as is. > Cheers, > Doru > > > On Oct 10, 2008, at 4:40 PM, Simon Denier wrote: > >> Thanks for your clarification, it helps! >> >> Now I can compare the generated code under VW with Squeak (as >> well as >> with Fame4Java but it's another story) >> >> The code seems fine except for Association>>below as well as >> Access>>isRead >> Both are implemented with 'self shoudBeImplemented' >> Both are derived attributes >> Association>>below is the opposite attribute of Association>>above >> It seems obvious that isRead is derived from isWrite. >> >> there should be some code at least to update the one-to-one >> relationship between above<->below. >> >> did I miss something? >>

_______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- Simon Denier, PhD Postdoc, Ptidej Team DIRO, Université de Montréal

Reply

Tudor Girba

4 p.m.

New subject: Importing Moose in Moose

Hi Jannik, Yes, I am aware of the problem. I guess you are using VW 7.6, because they introduced a bug in the latest version that causes this behavior. But, I think that they updated the VW 7.6 distribution because I do not get this bug anymore. Cheers, Doru On Oct 13, 2008, at 2:57 PM, Menanteau Jannick wrote:

...

Hi Doru, I would like to import Moose Package in a Moose Model, but I have an exception. The exception is : "Unhandled exception: NonBoolean". This appears on the Class "SampleData" When I delete this class, Moose package is imported. But this is not a good solution :) Have you any idea of the problem ? Thanks Jannik _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com www.tudorgirba.com/blog "We cannot reach the flow of things unless we let go."

Reply