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
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
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:
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
Moose-dev mailing list Moose-dev@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."
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.
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@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."
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@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@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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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."
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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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:
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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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:
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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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:
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@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@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@iam.unibe.ch To: Related to the development of Moose and other related tools moose-dev@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:
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@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@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@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@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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.
- on
On Sep 9, 2008, at 22:09, Stéphane Ducasse wrote:
tell me more since I integrated your changes, do I have to do it again did you work directly on famix20 classes? did you change/fix the changes I did?
Stef
On Sep 9, 2008, at 4:06 PM, Oscar Nierstrasz wrote:
Hi,
Doru and I looked at FMPragmaGenerator and ran it again.
The problem was that we needed to first set FMPragmaGenerator>>promptToAcceptChanges to return false so that the patches will be properly installed.
We have committed FAMIX2-Model-on.32. It should be ok now.
- on and tg
PS: We used Fame-on.65 to avoid any potential compatibility problems with Adrian's latest changes. (We didn't check if there were any.)
On Sep 6, 2008, at 21:30, Stéphane Ducasse wrote:
Ok what I did was to go over all the changes you did (as they show up in the refactoring window) and check the code and evaluate what was changed. I put back most of the famix2 code (but let the annotations that were introduced by your changes). I think that there should be one or two cases where I was confused and it would be good if you can have a look. \ The most intriguing one was incomingInvocations <MSEProperty: #incomingInvocations type: #FAMIXInvocation opposite: #candidates> <mulivalued> <derived> ^ incomingInvocations values
stef
On Sep 6, 2008, at 4:04 PM, Oscar Nierstrasz wrote:
In the FAMIX2 Meta -> Fame stuff, there is apparently a race condition that I did not realize.
So although we patch up the lazy initializers, this may be done in the wrong order.
I should sit together with Doru and have a look at it.
- on
On Sep 4, 2008, at 14:18, Stéphane Ducasse wrote:
The problem is that in Famix20 we have lazzy initializers and they got replaced by direct accessor. So signature was for example not lazzily computed anymore, and breaking the debugger. :(
So I do not know what is the contract stuff you are talking about but at the end it should be fixed.
Stef
On Sep 4, 2008, at 2:01 PM, Tudor Girba wrote:
The error I mentioned before is not due to the changes of Oscar and Toon. It's just that Fame has a different contract than Meta.
Doru
On Sep 4, 2008, at 1:54 PM, Stéphane Ducasse wrote:
> Apparently when applying blindly the changes of oscar I broke > FAMIX2 > (argh) > so I will take another image and check one by one the suggested > changes and produce a new Famx20 package > > Stef > On Sep 4, 2008, at 11:40 AM, Tudor Girba wrote: > >> Hi Stef, >> >> I know it breaks. The errors that you mention are due to the >> fact >> that >> some old classes from VW do not conform to Fame. >> >> That is why I said that for the moment just put there >> FAMIX2ModelRoot >> and then I will take a look at the code in the afternoon. >> >> Cheers, >> Doru >> >> >> On Sep 4, 2008, at 11:26 AM, Stéphane Ducasse wrote: >> >>> >>> On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote: >>> >>>> Hi, >>>> >>>> FAMIX2Class mooseDescription works only if the repository is >>>> correctly >>>> setup :). >>>> >>>> If you look in the code, then "MooseModel>>meta" is the one >>>> that >>>> returns the meta-model. >>> >>> Ah >>> I thought that we could plug any metamodel under fame >>> >>> >>> Now I did >>> >>> MooseModel2 class>>metaTower >>> "self resetMetaDescriptions. self metaTower" >>> >>> | pp | >>> ^metaTower ifNil: [ >>> pp := FMPragmaProcessor new. >>> pp queue: MooseEntity withAllSubclasses. >>> pp run. >>> metaTower := pp asTower] >>> >>> and I got a wonderful error which is a bad smell to me. >>> >>> >>> Stef >>> >>> >>> >>> >>> >>> >>> >>> >>>> It is lazily created and in the current >>>> implementation is starts the lookup from FAMIXEntity which >>>> does >>>> not >>>> include FAMIX2. >>>> >>>> I would suggest to make it FAMIX2ModelRoot for the moment >>>> just >>>> to >>>> make >>>> it work with your code. >>>> >>>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@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@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Im confused too :(
Here is what I did
I took fame-on65 run it and merged it then I run fame-on65 and went over all the conflicts and took back the method body that the automatic changes removed.
I was not aware of patch methods. So I will have a look at them. Stef
Hi Stef,
I am confused about the current status. I thought you rolled back to the previous FAMIX2 because you could not get the generated changes to work since the patches were missing. If our changes are already in FAMIX2, then all you need to do is to check the patches. They have moved to FameUtil. There is a protocol with several patch* methods. They can be run at any time. Just check if what you did is consistent with the patch* methods.
FMPragmaGenerator>>patchAllFAMIXspecialCases
I just loaded the latest version and checked the first patch:
patchFAMIX2AbstractBehaviouralEntity FAMIX2AbstractBehaviouralEntity compile: 'accesses "patched" <MSEProperty: #accesses type: #FAMIX2Access opposite: #accessedIn>
<multivalued> "all variable accesses contained in receiver" accesses isNil ifTrue: [ accesses := OrderedCollection new ]. ^ accesses'. ...
However if I look at FAMIX2AbstractBehaviouralEntity>>accesses I see this:
accesses <MSEProperty: #accesses type: #FAMIX2Access opposite: #accessedIn>
<multivalued>
self flag:#famix20Transfer. "in VW was incomingInvocations isNil ifTrue: [ incomingInvocations := OrderedCollection new ]. " ^ accesses
So I guess the patches have not been run.
To rerun the patches, simply evaluated the following:
(FMPragmaGenerator packageName: 'FAMIX2' rootClass: FAMIX2ModelRoot) patchAllFAMIXspecialCases
This will put back all the lazy initializers and fix all the other broken stuff.
I suggets you browse the patch* methods to see if you are convinced that they are ok.
ok I will
- on
On Sep 9, 2008, at 22:09, Stéphane Ducasse wrote:
tell me more since I integrated your changes, do I have to do it again did you work directly on famix20 classes? did you change/fix the changes I did?
Stef
On Sep 9, 2008, at 4:06 PM, Oscar Nierstrasz wrote:
Hi,
Doru and I looked at FMPragmaGenerator and ran it again.
The problem was that we needed to first set FMPragmaGenerator>>promptToAcceptChanges to return false so that the patches will be properly installed.
We have committed FAMIX2-Model-on.32. It should be ok now.
- on and tg
PS: We used Fame-on.65 to avoid any potential compatibility problems with Adrian's latest changes. (We didn't check if there were any.)
On Sep 6, 2008, at 21:30, Stéphane Ducasse wrote:
Ok what I did was to go over all the changes you did (as they show up in the refactoring window) and check the code and evaluate what was changed. I put back most of the famix2 code (but let the annotations that were introduced by your changes). I think that there should be one or two cases where I was confused and it would be good if you can have a look. \ The most intriguing one was incomingInvocations <MSEProperty: #incomingInvocations type: #FAMIXInvocation opposite: #candidates> <mulivalued> <derived> ^ incomingInvocations values
stef
On Sep 6, 2008, at 4:04 PM, Oscar Nierstrasz wrote:
In the FAMIX2 Meta -> Fame stuff, there is apparently a race condition that I did not realize.
So although we patch up the lazy initializers, this may be done in the wrong order.
I should sit together with Doru and have a look at it.
- on
On Sep 4, 2008, at 14:18, Stéphane Ducasse wrote:
The problem is that in Famix20 we have lazzy initializers and they got replaced by direct accessor. So signature was for example not lazzily computed anymore, and breaking the debugger. :(
So I do not know what is the contract stuff you are talking about but at the end it should be fixed.
Stef
On Sep 4, 2008, at 2:01 PM, Tudor Girba wrote:
> The error I mentioned before is not due to the changes of Oscar > and > Toon. It's just that Fame has a different contract than Meta. > > Doru > > > On Sep 4, 2008, at 1:54 PM, Stéphane Ducasse wrote: > >> Apparently when applying blindly the changes of oscar I broke >> FAMIX2 >> (argh) >> so I will take another image and check one by one the suggested >> changes and produce a new Famx20 package >> >> Stef >> On Sep 4, 2008, at 11:40 AM, Tudor Girba wrote: >> >>> Hi Stef, >>> >>> I know it breaks. The errors that you mention are due to the >>> fact >>> that >>> some old classes from VW do not conform to Fame. >>> >>> That is why I said that for the moment just put there >>> FAMIX2ModelRoot >>> and then I will take a look at the code in the afternoon. >>> >>> Cheers, >>> Doru >>> >>> >>> On Sep 4, 2008, at 11:26 AM, Stéphane Ducasse wrote: >>> >>>> >>>> On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote: >>>> >>>>> Hi, >>>>> >>>>> FAMIX2Class mooseDescription works only if the repository is >>>>> correctly >>>>> setup :). >>>>> >>>>> If you look in the code, then "MooseModel>>meta" is the one >>>>> that >>>>> returns the meta-model. >>>> >>>> Ah >>>> I thought that we could plug any metamodel under fame >>>> >>>> >>>> Now I did >>>> >>>> MooseModel2 class>>metaTower >>>> "self resetMetaDescriptions. self metaTower" >>>> >>>> | pp | >>>> ^metaTower ifNil: [ >>>> pp := FMPragmaProcessor new. >>>> pp queue: MooseEntity withAllSubclasses. >>>> pp run. >>>> metaTower := pp asTower] >>>> >>>> and I got a wonderful error which is a bad smell to me. >>>> >>>> >>>> Stef >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> It is lazily created and in the current >>>>> implementation is starts the lookup from FAMIXEntity which >>>>> does >>>>> not >>>>> include FAMIX2. >>>>> >>>>> I would suggest to make it FAMIX2ModelRoot for the moment >>>>> just >>>>> to >>>>> make >>>>> it work with your code. >>>>> >>>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev@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@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@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@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
You will probably find that the patch methods are doing what you tried to do by hand. (Of course we had to go through the methods by hand to build the patch methods, but at least the patches are documented.)
Hope that helps.
- on
On Sep 14, 2008, at 12:04, Stéphane Ducasse wrote:
Im confused too :(
Here is what I did
I took fame-on65 run it and merged it then I run fame-on65 and went over all the conflicts and took back the method body that the automatic changes removed.
I was not aware of patch methods. So I will have a look at them. Stef
Hi Stef,
I am confused about the current status. I thought you rolled back to the previous FAMIX2 because you could not get the generated changes to work since the patches were missing. If our changes are already in FAMIX2, then all you need to do is to check the patches. They have moved to FameUtil. There is a protocol with several patch* methods. They can be run at any time. Just check if what you did is consistent with the patch* methods.
FMPragmaGenerator>>patchAllFAMIXspecialCases
I just loaded the latest version and checked the first patch:
patchFAMIX2AbstractBehaviouralEntity FAMIX2AbstractBehaviouralEntity compile: 'accesses "patched" <MSEProperty: #accesses type: #FAMIX2Access opposite: #accessedIn>
<multivalued> "all variable accesses contained in receiver" accesses isNil ifTrue: [ accesses := OrderedCollection new ]. ^ accesses'. ...
However if I look at FAMIX2AbstractBehaviouralEntity>>accesses I see this:
accesses <MSEProperty: #accesses type: #FAMIX2Access opposite: #accessedIn>
<multivalued>
self flag:#famix20Transfer. "in VW was incomingInvocations isNil ifTrue: [ incomingInvocations := OrderedCollection new ]. " ^ accesses
So I guess the patches have not been run.
To rerun the patches, simply evaluated the following:
(FMPragmaGenerator packageName: 'FAMIX2' rootClass: FAMIX2ModelRoot) patchAllFAMIXspecialCases
This will put back all the lazy initializers and fix all the other broken stuff.
I suggets you browse the patch* methods to see if you are convinced that they are ok.
ok I will
- on
On Sep 9, 2008, at 22:09, Stéphane Ducasse wrote:
tell me more since I integrated your changes, do I have to do it again did you work directly on famix20 classes? did you change/fix the changes I did?
Stef
On Sep 9, 2008, at 4:06 PM, Oscar Nierstrasz wrote:
Hi,
Doru and I looked at FMPragmaGenerator and ran it again.
The problem was that we needed to first set FMPragmaGenerator>>promptToAcceptChanges to return false so that the patches will be properly installed.
We have committed FAMIX2-Model-on.32. It should be ok now.
- on and tg
PS: We used Fame-on.65 to avoid any potential compatibility problems with Adrian's latest changes. (We didn't check if there were any.)
On Sep 6, 2008, at 21:30, Stéphane Ducasse wrote:
Ok what I did was to go over all the changes you did (as they show up in the refactoring window) and check the code and evaluate what was changed. I put back most of the famix2 code (but let the annotations that were introduced by your changes). I think that there should be one or two cases where I was confused and it would be good if you can have a look. \ The most intriguing one was incomingInvocations <MSEProperty: #incomingInvocations type: #FAMIXInvocation opposite: #candidates> <mulivalued> <derived> ^ incomingInvocations values
stef
On Sep 6, 2008, at 4:04 PM, Oscar Nierstrasz wrote:
In the FAMIX2 Meta -> Fame stuff, there is apparently a race condition that I did not realize.
So although we patch up the lazy initializers, this may be done in the wrong order.
I should sit together with Doru and have a look at it.
- on
On Sep 4, 2008, at 14:18, Stéphane Ducasse wrote:
> The problem is that in Famix20 we have lazzy initializers and > they > got > replaced by direct accessor. > So signature was for example not lazzily computed anymore, and > breaking the debugger. :( > > So I do not know what is the contract stuff you are talking > about > but > at the end it should be fixed. > > Stef > > > On Sep 4, 2008, at 2:01 PM, Tudor Girba wrote: > >> The error I mentioned before is not due to the changes of Oscar >> and >> Toon. It's just that Fame has a different contract than Meta. >> >> Doru >> >> >> On Sep 4, 2008, at 1:54 PM, Stéphane Ducasse wrote: >> >>> Apparently when applying blindly the changes of oscar I broke >>> FAMIX2 >>> (argh) >>> so I will take another image and check one by one the >>> suggested >>> changes and produce a new Famx20 package >>> >>> Stef >>> On Sep 4, 2008, at 11:40 AM, Tudor Girba wrote: >>> >>>> Hi Stef, >>>> >>>> I know it breaks. The errors that you mention are due to the >>>> fact >>>> that >>>> some old classes from VW do not conform to Fame. >>>> >>>> That is why I said that for the moment just put there >>>> FAMIX2ModelRoot >>>> and then I will take a look at the code in the afternoon. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> On Sep 4, 2008, at 11:26 AM, Stéphane Ducasse wrote: >>>> >>>>> >>>>> On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> FAMIX2Class mooseDescription works only if the repository >>>>>> is >>>>>> correctly >>>>>> setup :). >>>>>> >>>>>> If you look in the code, then "MooseModel>>meta" is the one >>>>>> that >>>>>> returns the meta-model. >>>>> >>>>> Ah >>>>> I thought that we could plug any metamodel under fame >>>>> >>>>> >>>>> Now I did >>>>> >>>>> MooseModel2 class>>metaTower >>>>> "self resetMetaDescriptions. self metaTower" >>>>> >>>>> | pp | >>>>> ^metaTower ifNil: [ >>>>> pp := FMPragmaProcessor new. >>>>> pp queue: MooseEntity withAllSubclasses. >>>>> pp run. >>>>> metaTower := pp asTower] >>>>> >>>>> and I got a wonderful error which is a bad smell to me. >>>>> >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> It is lazily created and in the current >>>>>> implementation is starts the lookup from FAMIXEntity which >>>>>> does >>>>>> not >>>>>> include FAMIX2. >>>>>> >>>>>> I would suggest to make it FAMIX2ModelRoot for the moment >>>>>> just >>>>>> to >>>>>> make >>>>>> it work with your code. >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev@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@iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@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@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
I do not understand
I get
folders <MSEProperty: #folders type: #FAMIX2AbstractFile opposite: #belongsTo> <multivalued> ^ folders isNil ifTrue: [ folders := OrderedCollection new ].
in the code after applying the automatic conversion
now in the patch I get
FAMIX2Folder compile: 'folders "patched" <MSEProperty: #folders type: #FAMIX2Folder> <multivalued> folders isNil ifTrue: [ folders := OrderedCollection new ]. ^ folders'
Which one is correct? Since I do not know fame I do not understand.
Stef
On Sep 14, 2008, at 12:11 PM, Oscar Nierstrasz wrote:
You will probably find that the patch methods are doing what you tried to do by hand. (Of course we had to go through the methods by hand to build the patch methods, but at least the patches are documented.)
Hope that helps.
- on
On Sep 14, 2008, at 12:04, Stéphane Ducasse wrote:
Im confused too :(
Here is what I did
I took fame-on65 run it and merged it then I run fame-on65 and went over all the conflicts and took back the method body that the automatic changes removed.
I was not aware of patch methods. So I will have a look at them. Stef
Hi Stef,
I am confused about the current status. I thought you rolled back to the previous FAMIX2 because you could not get the generated changes to work since the patches were missing. If our changes are already in FAMIX2, then all you need to do is to check the patches. They have moved to FameUtil. There is a protocol with several patch* methods. They can be run at any time. Just check if what you did is consistent with the patch* methods.
FMPragmaGenerator>>patchAllFAMIXspecialCases
I just loaded the latest version and checked the first patch:
patchFAMIX2AbstractBehaviouralEntity FAMIX2AbstractBehaviouralEntity compile: 'accesses "patched" <MSEProperty: #accesses type: #FAMIX2Access opposite: #accessedIn>
<multivalued> "all variable accesses contained in receiver" accesses isNil ifTrue: [ accesses := OrderedCollection new ]. ^ accesses'. ...
However if I look at FAMIX2AbstractBehaviouralEntity>>accesses I see this:
accesses <MSEProperty: #accesses type: #FAMIX2Access opposite: #accessedIn>
<multivalued>
self flag:#famix20Transfer. "in VW was incomingInvocations isNil ifTrue: [ incomingInvocations := OrderedCollection new ]. " ^ accesses
So I guess the patches have not been run.
To rerun the patches, simply evaluated the following:
(FMPragmaGenerator packageName: 'FAMIX2' rootClass: FAMIX2ModelRoot) patchAllFAMIXspecialCases
This will put back all the lazy initializers and fix all the other broken stuff.
I suggets you browse the patch* methods to see if you are convinced that they are ok.
ok I will
- on
On Sep 9, 2008, at 22:09, Stéphane Ducasse wrote:
tell me more since I integrated your changes, do I have to do it again did you work directly on famix20 classes? did you change/fix the changes I did?
Stef
On Sep 9, 2008, at 4:06 PM, Oscar Nierstrasz wrote:
Hi,
Doru and I looked at FMPragmaGenerator and ran it again.
The problem was that we needed to first set FMPragmaGenerator>>promptToAcceptChanges to return false so that the patches will be properly installed.
We have committed FAMIX2-Model-on.32. It should be ok now.
- on and tg
PS: We used Fame-on.65 to avoid any potential compatibility problems with Adrian's latest changes. (We didn't check if there were any.)
On Sep 6, 2008, at 21:30, Stéphane Ducasse wrote:
Ok what I did was to go over all the changes you did (as they show up in the refactoring window) and check the code and evaluate what was changed. I put back most of the famix2 code (but let the annotations that were introduced by your changes). I think that there should be one or two cases where I was confused and it would be good if you can have a look. \ The most intriguing one was incomingInvocations <MSEProperty: #incomingInvocations type: #FAMIXInvocation opposite: #candidates> <mulivalued> <derived> ^ incomingInvocations values
stef
On Sep 6, 2008, at 4:04 PM, Oscar Nierstrasz wrote:
> > In the FAMIX2 Meta -> Fame stuff, there is apparently a race > condition > that I did not realize. > > So although we patch up the lazy initializers, this may be done > in > the > wrong order. > > I should sit together with Doru and have a look at it. > > - on > > On Sep 4, 2008, at 14:18, Stéphane Ducasse wrote: > >> The problem is that in Famix20 we have lazzy initializers and >> they >> got >> replaced by direct accessor. >> So signature was for example not lazzily computed anymore, and >> breaking the debugger. :( >> >> So I do not know what is the contract stuff you are talking >> about >> but >> at the end it should be fixed. >> >> Stef >> >> >> On Sep 4, 2008, at 2:01 PM, Tudor Girba wrote: >> >>> The error I mentioned before is not due to the changes of >>> Oscar >>> and >>> Toon. It's just that Fame has a different contract than Meta. >>> >>> Doru >>> >>> >>> On Sep 4, 2008, at 1:54 PM, Stéphane Ducasse wrote: >>> >>>> Apparently when applying blindly the changes of oscar I broke >>>> FAMIX2 >>>> (argh) >>>> so I will take another image and check one by one the >>>> suggested >>>> changes and produce a new Famx20 package >>>> >>>> Stef >>>> On Sep 4, 2008, at 11:40 AM, Tudor Girba wrote: >>>> >>>>> Hi Stef, >>>>> >>>>> I know it breaks. The errors that you mention are due to the >>>>> fact >>>>> that >>>>> some old classes from VW do not conform to Fame. >>>>> >>>>> That is why I said that for the moment just put there >>>>> FAMIX2ModelRoot >>>>> and then I will take a look at the code in the afternoon. >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> On Sep 4, 2008, at 11:26 AM, Stéphane Ducasse wrote: >>>>> >>>>>> >>>>>> On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> FAMIX2Class mooseDescription works only if the repository >>>>>>> is >>>>>>> correctly >>>>>>> setup :). >>>>>>> >>>>>>> If you look in the code, then "MooseModel>>meta" is the >>>>>>> one >>>>>>> that >>>>>>> returns the meta-model. >>>>>> >>>>>> Ah >>>>>> I thought that we could plug any metamodel under fame >>>>>> >>>>>> >>>>>> Now I did >>>>>> >>>>>> MooseModel2 class>>metaTower >>>>>> "self resetMetaDescriptions. self metaTower" >>>>>> >>>>>> | pp | >>>>>> ^metaTower ifNil: [ >>>>>> pp := FMPragmaProcessor new. >>>>>> pp queue: MooseEntity withAllSubclasses. >>>>>> pp run. >>>>>> metaTower := pp asTower] >>>>>> >>>>>> and I got a wonderful error which is a bad smell to me. >>>>>> >>>>>> >>>>>> Stef >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> It is lazily created and in the current >>>>>>> implementation is starts the lookup from FAMIXEntity which >>>>>>> does >>>>>>> not >>>>>>> include FAMIX2. >>>>>>> >>>>>>> I would suggest to make it FAMIX2ModelRoot for the moment >>>>>>> just >>>>>>> to >>>>>>> make >>>>>>> it work with your code. >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev@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@iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev@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@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com www.tudorgirba.com/blog
"Next time you see your life passing by, say 'hi' and get to know her."
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
-
Adrian Kuhn -
Oscar Nierstrasz -
Stéphane Ducasse -
Toon Verwaest -
Toon Verwaest -
Tudor Girba