Sorry, I have been swamped with meetings.
I will try to sit with Doru and/or Toon on Tuesday afternoon to sort it out.
- on
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@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
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev