I applied the FMPragmaGenerator and published a new version but I do not know how to access the description FAMIX2Class asMetaDescription does not work

Hi, FAMIX2Class mooseDescription works only if the repository is correctly setup :). If you look in the code, then "MooseModel>>meta" is the one that returns the meta-model.

It is lazily created and in the current implementation is starts the lookup from FAMIXEntity which does not include FAMIX2. I would suggest to make it FAMIX2ModelRoot for the moment just to make it work with your code.

Hi Stef, I know it breaks. The errors that you mention are due to the fact that some old classes from VW do not conform to Fame. That is why I said that for the moment just put there FAMIX2ModelRoot and then I will take a look at the code in the afternoon. Cheers, Doru On Sep 4, 2008, at 11:26 AM, Stéphane Ducasse wrote: > > On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote: > >> Hi, >> >> FAMIX2Class mooseDescription works only if the repository is >> correctly >> setup :). >> >> If you look in the code, then "MooseModel>>meta" is the one that >> returns the meta-model. > > Ah > I thought that we could plug any metamodel under fame > > > Now I did > > MooseModel2 class>>metaTower > "self resetMetaDescriptions. self metaTower" > > | pp | > ^metaTower ifNil: [ > pp := FMPragmaProcessor new. > pp queue: MooseEntity withAllSubclasses. > pp run. > metaTower := pp asTower] > > and I got a wonderful error which is a bad smell to me. > > > Stef > > > > > > > > >> It is lazily created and in the current >> implementation is starts the lookup from FAMIXEntity which does not >> include FAMIX2. >> >> I would suggest to make it FAMIX2ModelRoot for the moment just to >> make >> it work with your code. >> >> > _______________________________________________ > 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 "What we can governs what we wish." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

The error I mentioned before is not due to the changes of Oscar and Toon. It's just that Fame has a different contract than Meta. Doru On Sep 4, 2008, at 1:54 PM, Stéphane Ducasse wrote: > Apparently when applying blindly the changes of oscar I broke FAMIX2 > (argh) > so I will take another image and check one by one the suggested > changes and produce a new Famx20 package > > Stef > On Sep 4, 2008, at 11:40 AM, Tudor Girba wrote: > >> Hi Stef, >> >> I know it breaks. The errors that you mention are due to the fact >> that >> some old classes from VW do not conform to Fame. >> >> That is why I said that for the moment just put there >> FAMIX2ModelRoot >> and then I will take a look at the code in the afternoon. >> >> Cheers, >> Doru >> >> >> On Sep 4, 2008, at 11:26 AM, Stéphane Ducasse wrote: >> >>> >>> On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote: >>> >>>> Hi, >>>> >>>> FAMIX2Class mooseDescription works only if the repository is >>>> correctly >>>> setup :). >>>> >>>> If you look in the code, then "MooseModel>>meta" is the one that >>>> returns the meta-model. >>> >>> Ah >>> I thought that we could plug any metamodel under fame >>> >>> >>> Now I did >>> >>> MooseModel2 class>>metaTower >>> "self resetMetaDescriptions. self metaTower" >>> >>> | pp | >>> ^metaTower ifNil: [ >>> pp := FMPragmaProcessor new. >>> pp queue: MooseEntity withAllSubclasses. >>> pp run. >>> metaTower := pp asTower] >>> >>> and I got a wonderful error which is a bad smell to me. >>> >>> >>> Stef >>> >>> >>> >>> >>> >>> >>> >>> >>>> It is lazily created and in the current >>>> implementation is starts the lookup from FAMIXEntity which does >>>> not >>>> include FAMIX2. >>>> >>>> I would suggest to make it FAMIX2ModelRoot for the moment just to >>>> make >>>> it work with your code. >>>> >>>> >>> _______________________________________________ >>> 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 >> >> "What we can governs what we wish." >> >> >> >> _______________________________________________ >> 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 "Problem solving efficiency grows with the abstractness level of problem understanding." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

In the FAMIX2 Meta -> Fame stuff, there is apparently a race condition that I did not realize. So although we patch up the lazy initializers, this may be done in the wrong order. I should sit together with Doru and have a look at it. - on On Sep 4, 2008, at 14:18, Stéphane Ducasse wrote: > The problem is that in Famix20 we have lazzy initializers and they > got > replaced by direct accessor. > So signature was for example not lazzily computed anymore, and > breaking the debugger. :( > > So I do not know what is the contract stuff you are talking about but > at the end it should be fixed. > > Stef > > > On Sep 4, 2008, at 2:01 PM, Tudor Girba wrote: > >> The error I mentioned before is not due to the changes of Oscar and >> Toon. It's just that Fame has a different contract than Meta. >> >> Doru >> >> >> On Sep 4, 2008, at 1:54 PM, Stéphane Ducasse wrote: >> >>> Apparently when applying blindly the changes of oscar I broke >>> FAMIX2 >>> (argh) >>> so I will take another image and check one by one the suggested >>> changes and produce a new Famx20 package >>> >>> Stef >>> On Sep 4, 2008, at 11:40 AM, Tudor Girba wrote: >>> >>>> Hi Stef, >>>> >>>> I know it breaks. The errors that you mention are due to the fact >>>> that >>>> some old classes from VW do not conform to Fame. >>>> >>>> That is why I said that for the moment just put there >>>> FAMIX2ModelRoot >>>> and then I will take a look at the code in the afternoon. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> On Sep 4, 2008, at 11:26 AM, Stéphane Ducasse wrote: >>>> >>>>> >>>>> On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> FAMIX2Class mooseDescription works only if the repository is >>>>>> correctly >>>>>> setup :). >>>>>> >>>>>> If you look in the code, then "MooseModel>>meta" is the one that >>>>>> returns the meta-model. >>>>> >>>>> Ah >>>>> I thought that we could plug any metamodel under fame >>>>> >>>>> >>>>> Now I did >>>>> >>>>> MooseModel2 class>>metaTower >>>>> "self resetMetaDescriptions. self metaTower" >>>>> >>>>> | pp | >>>>> ^metaTower ifNil: [ >>>>> pp := FMPragmaProcessor new. >>>>> pp queue: MooseEntity withAllSubclasses. >>>>> pp run. >>>>> metaTower := pp asTower] >>>>> >>>>> and I got a wonderful error which is a bad smell to me. >>>>> >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> It is lazily created and in the current >>>>>> implementation is starts the lookup from FAMIXEntity which does >>>>>> not >>>>>> include FAMIX2. >>>>>> >>>>>> I would suggest to make it FAMIX2ModelRoot for the moment just >>>>>> to >>>>>> make >>>>>> it work with your code. >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> "What we can governs what we wish." >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> "Problem solving efficiency grows with the abstractness level of >> problem understanding." >> >> >> >> _______________________________________________ >> 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 > _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Ok what I did was to go over all the changes you did (as they show up in the refactoring window) and check the code and evaluate what was changed. I put back most of the famix2 code (but let the annotations that were introduced by your changes). I think that there should be one or two cases where I was confused and it would be good if you can have a look. \ The most intriguing one was incomingInvocations <MSEProperty: #incomingInvocations type: #FAMIXInvocation opposite: #candidates> <mulivalued> <derived> ^ incomingInvocations values stef On Sep 6, 2008, at 4:04 PM, Oscar Nierstrasz wrote: > > In the FAMIX2 Meta -> Fame stuff, there is apparently a race > condition > that I did not realize. > > So although we patch up the lazy initializers, this may be done in > the > wrong order. > > I should sit together with Doru and have a look at it. > > - on > > On Sep 4, 2008, at 14:18, Stéphane Ducasse wrote: > >> The problem is that in Famix20 we have lazzy initializers and they >> got >> replaced by direct accessor. >> So signature was for example not lazzily computed anymore, and >> breaking the debugger. :( >> >> So I do not know what is the contract stuff you are talking about >> but >> at the end it should be fixed. >> >> Stef >> >> >> On Sep 4, 2008, at 2:01 PM, Tudor Girba wrote: >> >>> The error I mentioned before is not due to the changes of Oscar and >>> Toon. It's just that Fame has a different contract than Meta. >>> >>> Doru >>> >>> >>> On Sep 4, 2008, at 1:54 PM, Stéphane Ducasse wrote: >>> >>>> Apparently when applying blindly the changes of oscar I broke >>>> FAMIX2 >>>> (argh) >>>> so I will take another image and check one by one the suggested >>>> changes and produce a new Famx20 package >>>> >>>> Stef >>>> On Sep 4, 2008, at 11:40 AM, Tudor Girba wrote: >>>> >>>>> Hi Stef, >>>>> >>>>> I know it breaks. The errors that you mention are due to the fact >>>>> that >>>>> some old classes from VW do not conform to Fame. >>>>> >>>>> That is why I said that for the moment just put there >>>>> FAMIX2ModelRoot >>>>> and then I will take a look at the code in the afternoon. >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> On Sep 4, 2008, at 11:26 AM, Stéphane Ducasse wrote: >>>>> >>>>>> >>>>>> On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> FAMIX2Class mooseDescription works only if the repository is >>>>>>> correctly >>>>>>> setup :). >>>>>>> >>>>>>> If you look in the code, then "MooseModel>>meta" is the one >>>>>>> that >>>>>>> returns the meta-model. >>>>>> >>>>>> Ah >>>>>> I thought that we could plug any metamodel under fame >>>>>> >>>>>> >>>>>> Now I did >>>>>> >>>>>> MooseModel2 class>>metaTower >>>>>> "self resetMetaDescriptions. self metaTower" >>>>>> >>>>>> | pp | >>>>>> ^metaTower ifNil: [ >>>>>> pp := FMPragmaProcessor new. >>>>>> pp queue: MooseEntity withAllSubclasses. >>>>>> pp run. >>>>>> metaTower := pp asTower] >>>>>> >>>>>> and I got a wonderful error which is a bad smell to me. >>>>>> >>>>>> >>>>>> Stef >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> It is lazily created and in the current >>>>>>> implementation is starts the lookup from FAMIXEntity which does >>>>>>> not >>>>>>> include FAMIX2. >>>>>>> >>>>>>> I would suggest to make it FAMIX2ModelRoot for the moment just >>>>>>> to >>>>>>> make >>>>>>> it work with your code. >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> "What we can governs what we wish." >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> "Problem solving efficiency grows with the abstractness level of >>> problem understanding." >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > > _______________________________________________ > 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

Ok what I did was to go over all the changes you did (as they show up in the refactoring window) and check the code and evaluate what was changed. I put back most of the famix2 code (but let the annotations that were introduced by your changes). I think that there should be one or two cases where I was confused and it would be good if you can have a look. \ The most intriguing one was incomingInvocations <MSEProperty: #incomingInvocations type: #FAMIXInvocation opposite: #candidates> <mulivalued> <derived> ^ incomingInvocations values stef On Sep 6, 2008, at 4:04 PM, Oscar Nierstrasz wrote: > > In the FAMIX2 Meta -> Fame stuff, there is apparently a race > condition > that I did not realize. > > So although we patch up the lazy initializers, this may be done in > the > wrong order. > > I should sit together with Doru and have a look at it. > > - on > > On Sep 4, 2008, at 14:18, Stéphane Ducasse wrote: > >> The problem is that in Famix20 we have lazzy initializers and they >> got >> replaced by direct accessor. >> So signature was for example not lazzily computed anymore, and >> breaking the debugger. :( >> >> So I do not know what is the contract stuff you are talking about >> but >> at the end it should be fixed. >> >> Stef >> >> >> On Sep 4, 2008, at 2:01 PM, Tudor Girba wrote: >> >>> The error I mentioned before is not due to the changes of Oscar and >>> Toon. It's just that Fame has a different contract than Meta. >>> >>> Doru >>> >>> >>> On Sep 4, 2008, at 1:54 PM, Stéphane Ducasse wrote: >>> >>>> Apparently when applying blindly the changes of oscar I broke >>>> FAMIX2 >>>> (argh) >>>> so I will take another image and check one by one the suggested >>>> changes and produce a new Famx20 package >>>> >>>> Stef >>>> On Sep 4, 2008, at 11:40 AM, Tudor Girba wrote: >>>> >>>>> Hi Stef, >>>>> >>>>> I know it breaks. The errors that you mention are due to the fact >>>>> that >>>>> some old classes from VW do not conform to Fame. >>>>> >>>>> That is why I said that for the moment just put there >>>>> FAMIX2ModelRoot >>>>> and then I will take a look at the code in the afternoon. >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> On Sep 4, 2008, at 11:26 AM, Stéphane Ducasse wrote: >>>>> >>>>>> >>>>>> On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> FAMIX2Class mooseDescription works only if the repository is >>>>>>> correctly >>>>>>> setup :). >>>>>>> >>>>>>> If you look in the code, then "MooseModel>>meta" is the one >>>>>>> that >>>>>>> returns the meta-model. >>>>>> >>>>>> Ah >>>>>> I thought that we could plug any metamodel under fame >>>>>> >>>>>> >>>>>> Now I did >>>>>> >>>>>> MooseModel2 class>>metaTower >>>>>> "self resetMetaDescriptions. self metaTower" >>>>>> >>>>>> | pp | >>>>>> ^metaTower ifNil: [ >>>>>> pp := FMPragmaProcessor new. >>>>>> pp queue: MooseEntity withAllSubclasses. >>>>>> pp run. >>>>>> metaTower := pp asTower] >>>>>> >>>>>> and I got a wonderful error which is a bad smell to me. >>>>>> >>>>>> >>>>>> Stef >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> It is lazily created and in the current >>>>>>> implementation is starts the lookup from FAMIXEntity which does >>>>>>> not >>>>>>> include FAMIX2. >>>>>>> >>>>>>> I would suggest to make it FAMIX2ModelRoot for the moment just >>>>>>> to >>>>>>> make >>>>>>> it work with your code. >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> "What we can governs what we wish." >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> "Problem solving efficiency grows with the abstractness level of >>> problem understanding." >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > > _______________________________________________ > 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

Hi, Doru and I looked at FMPragmaGenerator and ran it again. The problem was that we needed to first set FMPragmaGenerator>>promptToAcceptChanges to return false so that the patches will be properly installed. We have committed FAMIX2-Model-on.32. It should be ok now. - on and tg PS: We used Fame-on.65 to avoid any potential compatibility problems with Adrian's latest changes. (We didn't check if there were any.) On Sep 6, 2008, at 21:30, Stéphane Ducasse wrote: > Ok > what I did was to go over all the changes you did (as they show up in > the refactoring window) and check the code > and evaluate what was changed. I put back most of the famix2 code > (but > let the annotations that were introduced by your changes). > I think that there should be one or two cases where I was confused > and > it would be good if you can have a look. > \ > The most intriguing one was > incomingInvocations > <MSEProperty: #incomingInvocations type: #FAMIXInvocation opposite: > #candidates> <mulivalued> <derived> > ^ incomingInvocations values > > stef > > On Sep 6, 2008, at 4:04 PM, Oscar Nierstrasz wrote: > >> >> In the FAMIX2 Meta -> Fame stuff, there is apparently a race >> condition >> that I did not realize. >> >> So although we patch up the lazy initializers, this may be done in >> the >> wrong order. >> >> I should sit together with Doru and have a look at it. >> >> - on >> >> On Sep 4, 2008, at 14:18, Stéphane Ducasse wrote: >> >>> The problem is that in Famix20 we have lazzy initializers and they >>> got >>> replaced by direct accessor. >>> So signature was for example not lazzily computed anymore, and >>> breaking the debugger. :( >>> >>> So I do not know what is the contract stuff you are talking about >>> but >>> at the end it should be fixed. >>> >>> Stef >>> >>> >>> On Sep 4, 2008, at 2:01 PM, Tudor Girba wrote: >>> >>>> The error I mentioned before is not due to the changes of Oscar >>>> and >>>> Toon. It's just that Fame has a different contract than Meta. >>>> >>>> Doru >>>> >>>> >>>> On Sep 4, 2008, at 1:54 PM, Stéphane Ducasse wrote: >>>> >>>>> Apparently when applying blindly the changes of oscar I broke >>>>> FAMIX2 >>>>> (argh) >>>>> so I will take another image and check one by one the suggested >>>>> changes and produce a new Famx20 package >>>>> >>>>> Stef >>>>> On Sep 4, 2008, at 11:40 AM, Tudor Girba wrote: >>>>> >>>>>> Hi Stef, >>>>>> >>>>>> I know it breaks. The errors that you mention are due to the >>>>>> fact >>>>>> that >>>>>> some old classes from VW do not conform to Fame. >>>>>> >>>>>> That is why I said that for the moment just put there >>>>>> FAMIX2ModelRoot >>>>>> and then I will take a look at the code in the afternoon. >>>>>> >>>>>> Cheers, >>>>>> Doru >>>>>> >>>>>> >>>>>> On Sep 4, 2008, at 11:26 AM, Stéphane Ducasse wrote: >>>>>> >>>>>>> >>>>>>> On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> FAMIX2Class mooseDescription works only if the repository is >>>>>>>> correctly >>>>>>>> setup :). >>>>>>>> >>>>>>>> If you look in the code, then "MooseModel>>meta" is the one >>>>>>>> that >>>>>>>> returns the meta-model. >>>>>>> >>>>>>> Ah >>>>>>> I thought that we could plug any metamodel under fame >>>>>>> >>>>>>> >>>>>>> Now I did >>>>>>> >>>>>>> MooseModel2 class>>metaTower >>>>>>> "self resetMetaDescriptions. self metaTower" >>>>>>> >>>>>>> | pp | >>>>>>> ^metaTower ifNil: [ >>>>>>> pp := FMPragmaProcessor new. >>>>>>> pp queue: MooseEntity withAllSubclasses. >>>>>>> pp run. >>>>>>> metaTower := pp asTower] >>>>>>> >>>>>>> and I got a wonderful error which is a bad smell to me. >>>>>>> >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> It is lazily created and in the current >>>>>>>> implementation is starts the lookup from FAMIXEntity which >>>>>>>> does >>>>>>>> not >>>>>>>> include FAMIX2. >>>>>>>> >>>>>>>> I would suggest to make it FAMIX2ModelRoot for the moment just >>>>>>>> to >>>>>>>> make >>>>>>>> it work with your code. >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>>> "What we can governs what we wish." >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> "Problem solving efficiency grows with the abstractness level of >>>> problem understanding." >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> _______________________________________________ >> 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 > _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Hi Stef, I am confused about the current status. I thought you rolled back to the previous FAMIX2 because you could not get the generated changes to work since the patches were missing. If our changes are already in FAMIX2, then all you need to do is to check the patches. They have moved to FameUtil. There is a protocol with several patch* methods. They can be run at any time. Just check if what you did is consistent with the patch* methods. FMPragmaGenerator>>patchAllFAMIXspecialCases I just loaded the latest version and checked the first patch: patchFAMIX2AbstractBehaviouralEntity FAMIX2AbstractBehaviouralEntity compile: 'accesses "patched" <MSEProperty: #accesses type: #FAMIX2Access opposite: #accessedIn> <multivalued> "all variable accesses contained in receiver" accesses isNil ifTrue: [ accesses := OrderedCollection new ]. ^ accesses'. ... However if I look at FAMIX2AbstractBehaviouralEntity>>accesses I see this: accesses <MSEProperty: #accesses type: #FAMIX2Access opposite: #accessedIn> <multivalued> self flag:#famix20Transfer. "in VW was incomingInvocations isNil ifTrue: [ incomingInvocations := OrderedCollection new ]. " ^ accesses So I guess the patches have not been run. To rerun the patches, simply evaluated the following: (FMPragmaGenerator packageName: 'FAMIX2' rootClass: FAMIX2ModelRoot) patchAllFAMIXspecialCases This will put back all the lazy initializers and fix all the other broken stuff. I suggets you browse the patch* methods to see if you are convinced that they are ok.

- on On Sep 9, 2008, at 22:09, Stéphane Ducasse wrote: > tell me more > since I integrated your changes, do I have to do it again > did you work directly on famix20 classes? > did you change/fix the changes I did? > > Stef > > > On Sep 9, 2008, at 4:06 PM, Oscar Nierstrasz wrote: > >> >> Hi, >> >> Doru and I looked at FMPragmaGenerator and ran it again. >> >> The problem was that we needed to first set >> FMPragmaGenerator>>promptToAcceptChanges to return false so that the >> patches will be properly installed. >> >> We have committed FAMIX2-Model-on.32. It should be ok now. >> >> - on and tg >> >> PS: We used Fame-on.65 to avoid any potential compatibility problems >> with Adrian's latest changes. (We didn't check if there were any.) >> >> >> On Sep 6, 2008, at 21:30, Stéphane Ducasse wrote: >> >>> Ok >>> what I did was to go over all the changes you did (as they show up >>> in >>> the refactoring window) and check the code >>> and evaluate what was changed. I put back most of the famix2 code >>> (but >>> let the annotations that were introduced by your changes). >>> I think that there should be one or two cases where I was confused >>> and >>> it would be good if you can have a look. >>> \ >>> The most intriguing one was >>> incomingInvocations >>> <MSEProperty: #incomingInvocations type: #FAMIXInvocation >>> opposite: >>> #candidates> <mulivalued> <derived> >>> ^ incomingInvocations values >>> >>> stef >>> >>> On Sep 6, 2008, at 4:04 PM, Oscar Nierstrasz wrote: >>> >>>> >>>> In the FAMIX2 Meta -> Fame stuff, there is apparently a race >>>> condition >>>> that I did not realize. >>>> >>>> So although we patch up the lazy initializers, this may be done in >>>> the >>>> wrong order. >>>> >>>> I should sit together with Doru and have a look at it. >>>> >>>> - on >>>> >>>> On Sep 4, 2008, at 14:18, Stéphane Ducasse wrote: >>>> >>>>> The problem is that in Famix20 we have lazzy initializers and >>>>> they >>>>> got >>>>> replaced by direct accessor. >>>>> So signature was for example not lazzily computed anymore, and >>>>> breaking the debugger. :( >>>>> >>>>> So I do not know what is the contract stuff you are talking about >>>>> but >>>>> at the end it should be fixed. >>>>> >>>>> Stef >>>>> >>>>> >>>>> On Sep 4, 2008, at 2:01 PM, Tudor Girba wrote: >>>>> >>>>>> The error I mentioned before is not due to the changes of Oscar >>>>>> and >>>>>> Toon. It's just that Fame has a different contract than Meta. >>>>>> >>>>>> Doru >>>>>> >>>>>> >>>>>> On Sep 4, 2008, at 1:54 PM, Stéphane Ducasse wrote: >>>>>> >>>>>>> Apparently when applying blindly the changes of oscar I broke >>>>>>> FAMIX2 >>>>>>> (argh) >>>>>>> so I will take another image and check one by one the suggested >>>>>>> changes and produce a new Famx20 package >>>>>>> >>>>>>> Stef >>>>>>> On Sep 4, 2008, at 11:40 AM, Tudor Girba wrote: >>>>>>> >>>>>>>> Hi Stef, >>>>>>>> >>>>>>>> I know it breaks. The errors that you mention are due to the >>>>>>>> fact >>>>>>>> that >>>>>>>> some old classes from VW do not conform to Fame. >>>>>>>> >>>>>>>> That is why I said that for the moment just put there >>>>>>>> FAMIX2ModelRoot >>>>>>>> and then I will take a look at the code in the afternoon. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Doru >>>>>>>> >>>>>>>> >>>>>>>> On Sep 4, 2008, at 11:26 AM, Stéphane Ducasse wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> FAMIX2Class mooseDescription works only if the repository is >>>>>>>>>> correctly >>>>>>>>>> setup :). >>>>>>>>>> >>>>>>>>>> If you look in the code, then "MooseModel>>meta" is the one >>>>>>>>>> that >>>>>>>>>> returns the meta-model. >>>>>>>>> >>>>>>>>> Ah >>>>>>>>> I thought that we could plug any metamodel under fame >>>>>>>>> >>>>>>>>> >>>>>>>>> Now I did >>>>>>>>> >>>>>>>>> MooseModel2 class>>metaTower >>>>>>>>> "self resetMetaDescriptions. self metaTower" >>>>>>>>> >>>>>>>>> | pp | >>>>>>>>> ^metaTower ifNil: [ >>>>>>>>> pp := FMPragmaProcessor new. >>>>>>>>> pp queue: MooseEntity withAllSubclasses. >>>>>>>>> pp run. >>>>>>>>> metaTower := pp asTower] >>>>>>>>> >>>>>>>>> and I got a wonderful error which is a bad smell to me. >>>>>>>>> >>>>>>>>> >>>>>>>>> Stef >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> It is lazily created and in the current >>>>>>>>>> implementation is starts the lookup from FAMIXEntity which >>>>>>>>>> does >>>>>>>>>> not >>>>>>>>>> include FAMIX2. >>>>>>>>>> >>>>>>>>>> I would suggest to make it FAMIX2ModelRoot for the moment >>>>>>>>>> just >>>>>>>>>> to >>>>>>>>>> make >>>>>>>>>> it work with your code. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>>> >>>>>>>> "What we can governs what we wish." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>>> "Problem solving efficiency grows with the abstractness level of >>>>>> problem understanding." >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> _______________________________________________ >> 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 > _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

You will probably find that the patch methods are doing what you tried to do by hand. (Of course we had to go through the methods by hand to build the patch methods, but at least the patches are documented.) Hope that helps. - on On Sep 14, 2008, at 12:04, Stéphane Ducasse wrote: > Im confused too :( > > Here is what I did > > I took fame-on65 > run it and merged it > then I run fame-on65 and went over all the conflicts and > took back the method body that the automatic changes > removed. > > I was not aware of patch methods. So I will have a look at them. > Stef > >> >> Hi Stef, >> >> I am confused about the current status. I thought you rolled back >> to >> the previous FAMIX2 because you could not get the generated changes >> to >> work since the patches were missing. If our changes are already in >> FAMIX2, then all you need to do is to check the patches. They have >> moved to FameUtil. There is a protocol with several patch* >> methods. >> They can be run at any time. Just check if what you did is >> consistent >> with the patch* methods. >> >> FMPragmaGenerator>>patchAllFAMIXspecialCases >> >> I just loaded the latest version and checked the first patch: >> >> patchFAMIX2AbstractBehaviouralEntity >> FAMIX2AbstractBehaviouralEntity compile: 'accesses "patched" >> <MSEProperty: #accesses type: #FAMIX2Access opposite: #accessedIn> >> <multivalued> >> "all variable accesses contained in receiver" >> accesses isNil ifTrue: [ accesses := OrderedCollection new ]. >> ^ accesses'. >> ... >> >> However if I look at FAMIX2AbstractBehaviouralEntity>>accesses I see >> this: >> >> accesses >> <MSEProperty: #accesses type: #FAMIX2Access opposite: #accessedIn> >> <multivalued> >> >> self flag:#famix20Transfer. >> "in VW was incomingInvocations isNil ifTrue: >> [ incomingInvocations := OrderedCollection new ]. " >> ^ accesses >> >> So I guess the patches have not been run. >> >> To rerun the patches, simply evaluated the following: >> >> (FMPragmaGenerator packageName: 'FAMIX2' rootClass: FAMIX2ModelRoot) >> patchAllFAMIXspecialCases >> >> This will put back all the lazy initializers and fix all the other >> broken stuff. >> >> I suggets you browse the patch* methods to see if you are convinced >> that they are ok. > > ok I will > >> >> >> - on >> >> On Sep 9, 2008, at 22:09, Stéphane Ducasse wrote: >> >>> tell me more >>> since I integrated your changes, do I have to do it again >>> did you work directly on famix20 classes? >>> did you change/fix the changes I did? >>> >>> Stef >>> >>> >>> On Sep 9, 2008, at 4:06 PM, Oscar Nierstrasz wrote: >>> >>>> >>>> Hi, >>>> >>>> Doru and I looked at FMPragmaGenerator and ran it again. >>>> >>>> The problem was that we needed to first set >>>> FMPragmaGenerator>>promptToAcceptChanges to return false so that >>>> the >>>> patches will be properly installed. >>>> >>>> We have committed FAMIX2-Model-on.32. It should be ok now. >>>> >>>> - on and tg >>>> >>>> PS: We used Fame-on.65 to avoid any potential compatibility >>>> problems >>>> with Adrian's latest changes. (We didn't check if there were >>>> any.) >>>> >>>> >>>> On Sep 6, 2008, at 21:30, Stéphane Ducasse wrote: >>>> >>>>> Ok >>>>> what I did was to go over all the changes you did (as they show >>>>> up >>>>> in >>>>> the refactoring window) and check the code >>>>> and evaluate what was changed. I put back most of the famix2 code >>>>> (but >>>>> let the annotations that were introduced by your changes). >>>>> I think that there should be one or two cases where I was >>>>> confused >>>>> and >>>>> it would be good if you can have a look. >>>>> \ >>>>> The most intriguing one was >>>>> incomingInvocations >>>>> <MSEProperty: #incomingInvocations type: #FAMIXInvocation >>>>> opposite: >>>>> #candidates> <mulivalued> <derived> >>>>> ^ incomingInvocations values >>>>> >>>>> stef >>>>> >>>>> On Sep 6, 2008, at 4:04 PM, Oscar Nierstrasz wrote: >>>>> >>>>>> >>>>>> In the FAMIX2 Meta -> Fame stuff, there is apparently a race >>>>>> condition >>>>>> that I did not realize. >>>>>> >>>>>> So although we patch up the lazy initializers, this may be done >>>>>> in >>>>>> the >>>>>> wrong order. >>>>>> >>>>>> I should sit together with Doru and have a look at it. >>>>>> >>>>>> - on >>>>>> >>>>>> On Sep 4, 2008, at 14:18, Stéphane Ducasse wrote: >>>>>> >>>>>>> The problem is that in Famix20 we have lazzy initializers and >>>>>>> they >>>>>>> got >>>>>>> replaced by direct accessor. >>>>>>> So signature was for example not lazzily computed anymore, and >>>>>>> breaking the debugger. :( >>>>>>> >>>>>>> So I do not know what is the contract stuff you are talking >>>>>>> about >>>>>>> but >>>>>>> at the end it should be fixed. >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>>> On Sep 4, 2008, at 2:01 PM, Tudor Girba wrote: >>>>>>> >>>>>>>> The error I mentioned before is not due to the changes of >>>>>>>> Oscar >>>>>>>> and >>>>>>>> Toon. It's just that Fame has a different contract than Meta. >>>>>>>> >>>>>>>> Doru >>>>>>>> >>>>>>>> >>>>>>>> On Sep 4, 2008, at 1:54 PM, Stéphane Ducasse wrote: >>>>>>>> >>>>>>>>> Apparently when applying blindly the changes of oscar I broke >>>>>>>>> FAMIX2 >>>>>>>>> (argh) >>>>>>>>> so I will take another image and check one by one the >>>>>>>>> suggested >>>>>>>>> changes and produce a new Famx20 package >>>>>>>>> >>>>>>>>> Stef >>>>>>>>> On Sep 4, 2008, at 11:40 AM, Tudor Girba wrote: >>>>>>>>> >>>>>>>>>> Hi Stef, >>>>>>>>>> >>>>>>>>>> I know it breaks. The errors that you mention are due to the >>>>>>>>>> fact >>>>>>>>>> that >>>>>>>>>> some old classes from VW do not conform to Fame. >>>>>>>>>> >>>>>>>>>> That is why I said that for the moment just put there >>>>>>>>>> FAMIX2ModelRoot >>>>>>>>>> and then I will take a look at the code in the afternoon. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Doru >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Sep 4, 2008, at 11:26 AM, Stéphane Ducasse wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> FAMIX2Class mooseDescription works only if the repository >>>>>>>>>>>> is >>>>>>>>>>>> correctly >>>>>>>>>>>> setup :). >>>>>>>>>>>> >>>>>>>>>>>> If you look in the code, then "MooseModel>>meta" is the >>>>>>>>>>>> one >>>>>>>>>>>> that >>>>>>>>>>>> returns the meta-model. >>>>>>>>>>> >>>>>>>>>>> Ah >>>>>>>>>>> I thought that we could plug any metamodel under fame >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Now I did >>>>>>>>>>> >>>>>>>>>>> MooseModel2 class>>metaTower >>>>>>>>>>> "self resetMetaDescriptions. self metaTower" >>>>>>>>>>> >>>>>>>>>>> | pp | >>>>>>>>>>> ^metaTower ifNil: [ >>>>>>>>>>> pp := FMPragmaProcessor new. >>>>>>>>>>> pp queue: MooseEntity withAllSubclasses. >>>>>>>>>>> pp run. >>>>>>>>>>> metaTower := pp asTower] >>>>>>>>>>> >>>>>>>>>>> and I got a wonderful error which is a bad smell to me. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Stef >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> It is lazily created and in the current >>>>>>>>>>>> implementation is starts the lookup from FAMIXEntity which >>>>>>>>>>>> does >>>>>>>>>>>> not >>>>>>>>>>>> include FAMIX2. >>>>>>>>>>>> >>>>>>>>>>>> I would suggest to make it FAMIX2ModelRoot for the moment >>>>>>>>>>>> just >>>>>>>>>>>> to >>>>>>>>>>>> make >>>>>>>>>>>> it work with your code. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> "What we can governs what we wish." >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>>> >>>>>>>> "Problem solving efficiency grows with the abstractness level >>>>>>>> of >>>>>>>> problem understanding." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> _______________________________________________ >> 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 > _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

patchFAMIX2AbstractStructuralEntity FAMIX2AbstractStructuralEntity compile: 'accessedByLists "patched" <MSEProperty: #accessedByList type: #FAMIX2Access opposite: #accesses> <multivalued> ^ accessedByList' but there is no accessedByLists so is is normal? Stef _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

I will check with Toon. There was a lot of confusion with singular and plural method names, especially accessedByList and accessedByLists, as I recall. - on On Sep 15, 2008, at 22:03, Stéphane Ducasse wrote: > > > patchFAMIX2AbstractStructuralEntity > FAMIX2AbstractStructuralEntity compile: 'accessedByLists "patched" > <MSEProperty: #accessedByList type: #FAMIX2Access opposite: > #accesses> > <multivalued> > ^ accessedByList' > > but there is no accessedByLists > so is is normal? > > Stef > _______________________________________________ > 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

OK, good. Sorry to have missed this point when we went over it at ESUG. So the FAMIX2 -> FAME translation is now complete? Cheers, - on On Sep 16, 2008, at 8:55, Stéphane Ducasse wrote: > For now > I went over all the pacth methods, applied them by hand and > apparently > my previous green tests are green again. > > Stef > > On Sep 15, 2008, at 10:58 PM, Oscar Nierstrasz wrote: > >> >> I will check with Toon. >> >> There was a lot of confusion with singular and plural method names, >> especially accessedByList and accessedByLists, as I recall. >> >> - on >> >> On Sep 15, 2008, at 22:03, Stéphane Ducasse wrote: >> >>> >>> >>> patchFAMIX2AbstractStructuralEntity >>> FAMIX2AbstractStructuralEntity compile: 'accessedByLists "patched" >>> <MSEProperty: #accessedByList type: #FAMIX2Access opposite: >>> #accesses> >>> <multivalued> >>> ^ accessedByList' >>> >>> but there is no accessedByLists >>> so is is normal? >>> >>> Stef >>> _______________________________________________ >>> 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 >> > > > _______________________________________________ > 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