7 Sep
2008
7 Sep
'08
12:50 a.m.
This is probably because of the slot-objects which are generated by the
codegenerator for properties with an opposite. This one clearly has an
opposite so to get the actually value, in code where you use objects for
slots, you have to call values on it. I guess that if you use a
different strategy for handling opposites, you don't wont to have the
"values" message sent.
Or was there something else?
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:
_______________________________________________
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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