I do not understand
I get
folders
<MSEProperty: #folders type: #FAMIX2AbstractFile opposite:
#belongsTo> <multivalued>
^ folders isNil ifTrue: [ folders := OrderedCollection new ].
in the code after applying the automatic conversion
now in the patch I get
FAMIX2Folder compile: 'folders "patched"
<MSEProperty: #folders type: #FAMIX2Folder>
<multivalued>
folders isNil ifTrue: [ folders := OrderedCollection new ].
^ folders'
Which one is correct?
Since I do not know fame I do not understand.
Stef
On Sep 14, 2008, at 12:11 PM, Oscar Nierstrasz wrote:
You will probably find that the patch methods are doing what you tried
to do by hand.
(Of course we had to go through the methods by hand to build the patch
methods, but at least the patches are documented.)
Hope that helps.
- on
On Sep 14, 2008, at 12:04, Stéphane Ducasse wrote:
> Im confused too :(
>
> Here is what I did
>
> I took fame-on65
> run it and merged it
> then I run fame-on65 and went over all the conflicts and
> took back the method body that the automatic changes
> removed.
>
> I was not aware of patch methods. So I will have a look at them.
> Stef
>
>>
>> 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.
>
> ok I will
>
>>
>>
>> - 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:
>>>>
>>>>> 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
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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