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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev