14 Sep
2008
14 Sep
'08
9:19 a.m.
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:
_______________________________________________
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:
_______________________________________________
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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev