9 Sep
2008
9 Sep
'08
5:04 p.m.
Oh right, that thing. I knew that we were going to forget that one :)
On (09/09/08 16:06), Oscar Nierstrasz wrote:
From: Oscar Nierstrasz <oscar(a)iam.unibe.ch>
To: Related to the development of Moose and other related tools
<moose-dev(a)iam.unibe.ch>
Subject: [Moose-dev] Re: FMPragmaGenerator generateFAMIX2annotations
metamodel explore
Date: Tue, 9 Sep 2008 16:06:02 +0200
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:
_______________________________________________
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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