4 Sep
2008
4 Sep
'08
10:48 a.m.
Does not work anymore in the latest version of FAME.
Well...
So I will rollback to an old version of Fame to perform the changes.
Stef
4 Sep
4 Sep
10:57 a.m.
New subject: FMPragmaGenerator generateFAMIX2annotations metamodel explore
I applied the FMPragmaGenerator and published a new version but I do
not know
how to access the description
FAMIX2Class asMetaDescription does not work
How do I get that stuff to work?
I really think that we got too meta.... sadly.
Stef
Does not work anymore in the latest version of FAME.
Well...
So I will rollback to an old version of Fame to perform the changes.
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:06 a.m.
New subject: FMPragmaGenerator generateFAMIX2annotations metamodel explore
How do I get FAMIX2 descriptions declared and used so that FAMIX2Class
mooseDescription works
MooseModel resetMetaDescriptions
does not seem to
On Sep 4, 2008, at 10:57 AM, Stéphane Ducasse wrote:
I applied the FMPragmaGenerator and published a new
version but I do
not know
how to access the description
FAMIX2Class asMetaDescription does not work
FAMIX2Class mooseDescription does not work
11:15 a.m.
New subject: FMPragmaGenerator generateFAMIX2annotations metamodel explore
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. 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.
Cheers,
Doru
On Sep 4, 2008, at 11:06 AM, Stéphane Ducasse wrote:
How do I get FAMIX2 descriptions declared and used so
that FAMIX2Class
mooseDescription works
MooseModel resetMetaDescriptions
does not seem to
On Sep 4, 2008, at 10:57 AM, Stéphane Ducasse wrote:
_______________________________________________
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
"Obvious things are difficult to teach."
I applied the FMPragmaGenerator and published a
new version but I do
not know
how to access the description
FAMIX2Class asMetaDescription does not work
FAMIX2Class mooseDescription does not work
11:26 a.m.
New subject: FMPragmaGenerator generateFAMIX2annotations metamodel explore
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.
11:40 a.m.
New subject: FMPragmaGenerator generateFAMIX2annotations metamodel explore
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:
--
www.tudorgirba.com
www.tudorgirba.com/blog
"What we can governs what we wish."
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
1:54 p.m.
New subject: FMPragmaGenerator generateFAMIX2annotations metamodel explore
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:
--
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
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
2:01 p.m.
New subject: FMPragmaGenerator generateFAMIX2annotations metamodel explore
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:
--
www.tudorgirba.com
www.tudorgirba.com/blog
"Problem solving efficiency grows with the abstractness level of
problem understanding."
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote:
--
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
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
2:18 p.m.
New subject: FMPragmaGenerator generateFAMIX2annotations metamodel explore
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:
--
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
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
6 Sep
6 Sep
4:04 p.m.
New subject: FMPragmaGenerator generateFAMIX2annotations metamodel explore
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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:
--
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
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
9:30 p.m.
New subject: FMPragmaGenerator generateFAMIX2annotations metamodel explore
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:
_______________________________________________
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
7 Sep
7 Sep
12:50 a.m.
New subject: FMPragmaGenerator generateFAMIX2annotations metamodel explore
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
8 Sep
8 Sep
8:34 p.m.
New subject: FMPragmaGenerator generateFAMIX2annotations metamodel explore
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:
_______________________________________________
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
9:22 p.m.
New subject: FMPragmaGenerator generateFAMIX2annotations metamodel explore
No problem we are all swamped with meetings and works (and house
fixing and kid juggling :)).
Stef
On Sep 8, 2008, at 8:34 PM, Oscar Nierstrasz wrote:
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:
_______________________________________________
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
9 Sep
9 Sep
4:06 p.m.
New subject: FMPragmaGenerator generateFAMIX2annotations metamodel explore
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:
_______________________________________________
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
5:04 p.m.
New subject: FMPragmaGenerator generateFAMIX2annotations metamodel explore
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
10:09 p.m.
New subject: FMPragmaGenerator generateFAMIX2annotations metamodel explore
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:
_______________________________________________
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
14 Sep
14 Sep
9:19 a.m.
New subject: FMPragmaGenerator generateFAMIX2annotations metamodel explore
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
12:04 p.m.
New subject: FMPragmaGenerator generateFAMIX2annotations metamodel explore
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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:
>
> 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
12:11 p.m.
New subject: FMPragmaGenerator generateFAMIX2annotations metamodel explore
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
15 Sep
15 Sep
9:59 p.m.
New subject: FMPragmaGenerator generateFAMIX2annotations metamodel explore
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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
10:03 p.m.
New subject: FMPragmaGenerator generateFAMIX2annotations metamodel explore
patchFAMIX2AbstractStructuralEntity
FAMIX2AbstractStructuralEntity compile: 'accessedByLists "patched"
<MSEProperty: #accessedByList type: #FAMIX2Access opposite: #accesses>
<multivalued>
^ accessedByList'
but there is no accessedByLists
so is is normal?
Stef
10:58 p.m.
New subject: FMPragmaGenerator generateFAMIX2annotations metamodel explore
I will check with Toon.
There was a lot of confusion with singular and plural method names,
especially accessedByList and accessedByLists, as I recall.
- on
On Sep 15, 2008, at 22:03, Stéphane Ducasse wrote:
patchFAMIX2AbstractStructuralEntity
FAMIX2AbstractStructuralEntity compile: 'accessedByLists "patched"
<MSEProperty: #accessedByList type: #FAMIX2Access opposite:
#accesses>
<multivalued>
^ accessedByList'
but there is no accessedByLists
so is is normal?
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:01 p.m.
New subject: FMPragmaGenerator generateFAMIX2annotations metamodel explore
This was a dirty quick fix to make Moose work in VW. accessedByLists
should be removed altogether.
Cheers,
Doru
On Sep 15, 2008, at 10:58 PM, Oscar Nierstrasz wrote:
I will check with Toon.
There was a lot of confusion with singular and plural method names,
especially accessedByList and accessedByLists, as I recall.
- on
On Sep 15, 2008, at 22:03, Stéphane Ducasse wrote:
--
www.tudorgirba.com
www.tudorgirba.com/blog
"Next time you see your life passing by, say 'hi' and get to know her."
patchFAMIX2AbstractStructuralEntity
FAMIX2AbstractStructuralEntity compile: 'accessedByLists "patched"
<MSEProperty: #accessedByList type: #FAMIX2Access opposite:
#accesses>
<multivalued>
^ accessedByList'
but there is no accessedByLists
so is is normal?
Stef
_______________________________________________
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
16 Sep
16 Sep
8:55 a.m.
New subject: FMPragmaGenerator generateFAMIX2annotations metamodel explore
For now
I went over all the pacth methods, applied them by hand and apparently
my previous green tests are green again.
Stef
On Sep 15, 2008, at 10:58 PM, Oscar Nierstrasz wrote:
I will check with Toon.
There was a lot of confusion with singular and plural method names,
especially accessedByList and accessedByLists, as I recall.
- on
On Sep 15, 2008, at 22:03, Stéphane Ducasse wrote:
patchFAMIX2AbstractStructuralEntity
FAMIX2AbstractStructuralEntity compile: 'accessedByLists "patched"
<MSEProperty: #accessedByList type: #FAMIX2Access opposite:
#accesses>
<multivalued>
^ accessedByList'
but there is no accessedByLists
so is is normal?
Stef
_______________________________________________
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
9:27 a.m.
New subject: FMPragmaGenerator generateFAMIX2annotations metamodel explore
OK, good. Sorry to have missed this point when we went over it at ESUG.
So the FAMIX2 -> FAME translation is now complete?
Cheers,
- on
On Sep 16, 2008, at 8:55, Stéphane Ducasse wrote:
For now
I went over all the pacth methods, applied them by hand and apparently
my previous green tests are green again.
Stef
On Sep 15, 2008, at 10:58 PM, Oscar Nierstrasz wrote:
I will check with Toon.
There was a lot of confusion with singular and plural method names,
especially accessedByList and accessedByLists, as I recall.
- on
On Sep 15, 2008, at 22:03, Stéphane Ducasse wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
patchFAMIX2AbstractStructuralEntity
FAMIX2AbstractStructuralEntity compile: 'accessedByLists "patched"
<MSEProperty: #accessedByList type: #FAMIX2Access opposite:
#accesses>
<multivalued>
^ accessedByList'
but there is no accessedByLists
so is is normal?
Stef
_______________________________________________
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
9:36 a.m.
New subject: FMPragmaGenerator generateFAMIX2annotations metamodel explore
I imagine it is.
I will check the old emails and this is done.
Now where I would need help is to get Fame used as in the group and
other UI...
Alex could not make the repository filled up with the right description.
I want to be able to do
FAMIX2Class asDescription and get it.
Stef
On Sep 16, 2008, at 9:27 AM, Oscar Nierstrasz wrote:
OK, good. Sorry to have missed this point when we went over it at
ESUG.
So the FAMIX2 -> FAME translation is now complete?
Cheers,
- on
On Sep 16, 2008, at 8:55, Stéphane Ducasse wrote:
For now
I went over all the pacth methods, applied them by hand and
apparently
my previous green tests are green again.
Stef
On Sep 15, 2008, at 10:58 PM, Oscar Nierstrasz wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
I will check with Toon.
There was a lot of confusion with singular and plural method names,
especially accessedByList and accessedByLists, as I recall.
- on
On Sep 15, 2008, at 22:03, Stéphane Ducasse wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
patchFAMIX2AbstractStructuralEntity
FAMIX2AbstractStructuralEntity compile: 'accessedByLists "patched"
<MSEProperty: #accessedByList type: #FAMIX2Access opposite:
#accesses>
<multivalued>
^ accessedByList'
but there is no accessedByLists
so is is normal?
Stef
_______________________________________________
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
4 Sep
4 Sep
11:32 a.m.
New subject: FMPragmaGenerator generateFAMIX2annotations metamodel explore
FMPragmaGenerator is part of the migration code written by Oscar and
Toon. It may be that I have broken their code since it is not covered
by tests. Please contact them for more help.
cheers,
AA
On 4 Sep 2008, at 11:06 , Stéphane Ducasse wrote:
How do I get FAMIX2 descriptions declared and used so
that
FAMIX2Class mooseDescription works
MooseModel resetMetaDescriptions
does not seem to
On Sep 4, 2008, at 10:57 AM, Stéphane Ducasse wrote:
I applied the FMPragmaGenerator and published a
new version but I do
not know
how to access the description
FAMIX2Class asMetaDescription does not work
FAMIX2Class mooseDescription does not work
>
6089
days inactive
6101
days old
27 comments
6 participants
participants (6)
-
Adrian Kuhn -
Oscar Nierstrasz -
Stéphane Ducasse -
Toon Verwaest -
Toon Verwaest -
Tudor Girba