[Moose-dev] Re: FMPragmaGenerator generateFAMIX2annotations metamodel explore

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