Famix2MSE importer Available in PharoMoose
Locked
12
12
Famix2MSE importer Available in PharoMoose
 
|
Hi all,
With Cyrille we work on a Famix2MseImporter in Pharo Famix3. It is a hack, in two parts: First, we place a script between the parser and the MooseElement creation. So this script switches elements of Famix2 to Famix3. For example, a FAMIX.InheritanceDefinition in the Famix2Mse become a FamixInheritance in Famix3. The other part of the script appears after the mooseModel creation. In Famix3, there are FamixAccess and FamixReference. But in Famix2, there is only FamixAccess. FamixReference is for a target with type FamixClass. But, when the parser works, it is not easily possible to know the type of an attribute. So, to do it easy, when the MooseModel is created, we check all accesses and test if the target is a FamixClass. If true, the script change the link in a FamixReference. Now, we have three elements with no possible switch: - there is no FAMIXGlobalVariable>>declaredType in Famix2. - in Famix3, FAMIXInvocation>>receivingVariable has disappeared. - in Famix3, FAMIXParameter>>position has disappeared. The meta-informations in Famix2Mse are not taken account. Finally, this script is a hack, the aim is to provide a solution for people who want to come to Pharo-Moose. You can load it with: Gofer new squeaksource: 'Famix2Importer'; package: 'Famix2Importer'; load. A menu item is available in MoosePanel menu. You can try it and mail us if you have some bugs. Cheers, Jannik and Cyrille. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Famix2MSE importer Available in PharoMoose
|
|
On 16 févr. 2010, at 11:06, Laval Jannik wrote: > Hi all, > > With Cyrille we work on a Famix2MseImporter in Pharo Famix3. > > It is a hack, in two parts: > First, we place a script between the parser and the MooseElement creation. So this script switches elements of Famix2 to Famix3. For example, a FAMIX.InheritanceDefinition in the Famix2Mse become a FamixInheritance in Famix3. > > The other part of the script appears after the mooseModel creation. In Famix3, there are FamixAccess and FamixReference. But in Famix2, there is only FamixAccess. > FamixReference is for a target with type FamixClass. But, when the parser works, it is not easily possible to know the type of an attribute. So, to do it easy, when the MooseModel is created, we check all accesses and test if the target is a FamixClass. If true, the script change the link in a FamixReference. > > Now, we have three elements with no possible switch: > - there is no FAMIXGlobalVariable>>declaredType in Famix2. > - in Famix3, FAMIXInvocation>>receivingVariable has disappeared. I think this is replaced by FAMIXInvocation>>receiver > - in Famix3, FAMIXParameter>>position has disappeared. > > The meta-informations in Famix2Mse are not taken account. > > Finally, this script is a hack, the aim is to provide a solution for people who want to come to Pharo-Moose. > > You can load it with: > > Gofer new > squeaksource: 'Famix2Importer'; > package: 'Famix2Importer'; > load. > > A menu item is available in MoosePanel menu. > You can try it and mail us if you have some bugs. > > Cheers, > Jannik and Cyrille. > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Famix2MSE importer Available in PharoMoose
|
|
Nice initiative!
However, I could not make it load any of my case studies. I get syntax error. Could you provide an example that works? Cheers, Doru On 16 Feb 2010, at 12:24, Simon Denier wrote: > > On 16 févr. 2010, at 11:06, Laval Jannik wrote: > >> Hi all, >> >> With Cyrille we work on a Famix2MseImporter in Pharo Famix3. >> >> It is a hack, in two parts: >> First, we place a script between the parser and the MooseElement >> creation. So this script switches elements of Famix2 to Famix3. For >> example, a FAMIX.InheritanceDefinition in the Famix2Mse become a >> FamixInheritance in Famix3. >> >> The other part of the script appears after the mooseModel creation. >> In Famix3, there are FamixAccess and FamixReference. But in Famix2, >> there is only FamixAccess. >> FamixReference is for a target with type FamixClass. But, when the >> parser works, it is not easily possible to know the type of an >> attribute. So, to do it easy, when the MooseModel is created, we >> check all accesses and test if the target is a FamixClass. If true, >> the script change the link in a FamixReference. >> >> Now, we have three elements with no possible switch: >> - there is no FAMIXGlobalVariable>>declaredType in Famix2. >> - in Famix3, FAMIXInvocation>>receivingVariable has disappeared. > > I think this is replaced by FAMIXInvocation>>receiver > >> - in Famix3, FAMIXParameter>>position has disappeared. >> >> The meta-informations in Famix2Mse are not taken account. >> >> Finally, this script is a hack, the aim is to provide a solution >> for people who want to come to Pharo-Moose. >> >> You can load it with: >> >> Gofer new >> squeaksource: 'Famix2Importer'; >> package: 'Famix2Importer'; >> load. >> >> A menu item is available in MoosePanel menu. >> You can try it and mail us if you have some bugs. >> >> Cheers, >> Jannik and Cyrille. >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Every thing has its own flow." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hello,
I join an example that works for me. But I think the problem could come from the head of your files, because I'm really not sure about how does a famix2mse file begin with. Can you send me your files ?
2010/2/16 Tudor Girba <[hidden email]> Nice initiative! _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
LAN sample model-3.famix2.mse (133K) |
|
---------- Forwarded message ---------- From: Cyrille Delaunay <[hidden email]> Date: 2010/2/16 Subject: Re: [Moose-dev] Re: Famix2MSE importer Available in PharoMoose To: Related to the development of Moose and other related tools <[hidden email]> Hello, I join an example that works for me. But I think the problem could come from the head of your files, because I'm really not sure about how does a famix2mse file begin with. Can you send me your files ?
2010/2/16 Tudor Girba <[hidden email]> Nice initiative! _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Famix2MSE importer Available in PharoMoose
|
|
In reply to this post by cdelaunay
Hi guys,
very cool! (Doru: sorry for not responding earlier. I only noticed your reply now) I just tried the attached mse file and got an error when the 'kind' of a method was being set to 'abstract'. I'm trying to figure out how I can help to complete this. My first guess was to edit the MethodAttributesTraduction dictionary initialization in the FM2TradInit method to correct that. However, what can the 'kind' be in a Famix2 file? Since Famix3 has the same 'kind' attribute, I guess that only the value 'abstract' should no longer be in there, right? Do you have an example in the converter where that already occurs? cheers Johan On 16 Feb 2010, at 12:44, Cyrille Delaunay wrote: > Hello, > I join an example that works for me. But I think the problem could come from the head of your files, because I'm really not sure about how does a famix2mse file begin with. Can you send me your files ? > > 2010/2/16 Tudor Girba <[hidden email]> > Nice initiative! > > However, I could not make it load any of my case studies. I get syntax error. Could you provide an example that works? > > Cheers, > Doru > > > > On 16 Feb 2010, at 12:24, Simon Denier wrote: > > > On 16 févr. 2010, at 11:06, Laval Jannik wrote: > > Hi all, > > With Cyrille we work on a Famix2MseImporter in Pharo Famix3. > > It is a hack, in two parts: > First, we place a script between the parser and the MooseElement creation. So this script switches elements of Famix2 to Famix3. For example, a FAMIX.InheritanceDefinition in the Famix2Mse become a FamixInheritance in Famix3. > > The other part of the script appears after the mooseModel creation. In Famix3, there are FamixAccess and FamixReference. But in Famix2, there is only FamixAccess. > FamixReference is for a target with type FamixClass. But, when the parser works, it is not easily possible to know the type of an attribute. So, to do it easy, when the MooseModel is created, we check all accesses and test if the target is a FamixClass. If true, the script change the link in a FamixReference. > > Now, we have three elements with no possible switch: > - there is no FAMIXGlobalVariable>>declaredType in Famix2. > - in Famix3, FAMIXInvocation>>receivingVariable has disappeared. > > I think this is replaced by FAMIXInvocation>>receiver > > - in Famix3, FAMIXParameter>>position has disappeared. > > The meta-informations in Famix2Mse are not taken account. > > Finally, this script is a hack, the aim is to provide a solution for people who want to come to Pharo-Moose. > > You can load it with: > > Gofer new > squeaksource: 'Famix2Importer'; > package: 'Famix2Importer'; > load. > > A menu item is available in MoosePanel menu. > You can try it and mail us if you have some bugs. > > Cheers, > Jannik and Cyrille. > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Every thing has its own flow." > > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > <LAN sample model-3.famix2.mse>_______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev ---------------------------- Johan Brichau [hidden email] _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Famix2MSE importer Available in PharoMoose
|
|
now with my attachment... (sorry)
On 16 Feb 2010, at 20:50, Johan Brichau wrote: > Hi guys, > > very cool! > (Doru: sorry for not responding earlier. I only noticed your reply now) > > I just tried the attached mse file and got an error when the 'kind' of a method was being set to 'abstract'. > > I'm trying to figure out how I can help to complete this. My first guess was to edit the MethodAttributesTraduction dictionary initialization in the FM2TradInit method to correct that. However, what can the 'kind' be in a Famix2 file? Since Famix3 has the same 'kind' attribute, I guess that only the value 'abstract' should no longer be in there, right? Do you have an example in the converter where that already occurs? > > cheers > Johan > > On 16 Feb 2010, at 12:44, Cyrille Delaunay wrote: > >> Hello, >> I join an example that works for me. But I think the problem could come from the head of your files, because I'm really not sure about how does a famix2mse file begin with. Can you send me your files ? >> >> 2010/2/16 Tudor Girba <[hidden email]> >> Nice initiative! >> >> However, I could not make it load any of my case studies. I get syntax error. Could you provide an example that works? >> >> Cheers, >> Doru >> >> >> >> On 16 Feb 2010, at 12:24, Simon Denier wrote: >> >> >> On 16 févr. 2010, at 11:06, Laval Jannik wrote: >> >> Hi all, >> >> With Cyrille we work on a Famix2MseImporter in Pharo Famix3. >> >> It is a hack, in two parts: >> First, we place a script between the parser and the MooseElement creation. So this script switches elements of Famix2 to Famix3. For example, a FAMIX.InheritanceDefinition in the Famix2Mse become a FamixInheritance in Famix3. >> >> The other part of the script appears after the mooseModel creation. In Famix3, there are FamixAccess and FamixReference. But in Famix2, there is only FamixAccess. >> FamixReference is for a target with type FamixClass. But, when the parser works, it is not easily possible to know the type of an attribute. So, to do it easy, when the MooseModel is created, we check all accesses and test if the target is a FamixClass. If true, the script change the link in a FamixReference. >> >> Now, we have three elements with no possible switch: >> - there is no FAMIXGlobalVariable>>declaredType in Famix2. >> - in Famix3, FAMIXInvocation>>receivingVariable has disappeared. >> >> I think this is replaced by FAMIXInvocation>>receiver >> >> - in Famix3, FAMIXParameter>>position has disappeared. >> >> The meta-informations in Famix2Mse are not taken account. >> >> Finally, this script is a hack, the aim is to provide a solution for people who want to come to Pharo-Moose. >> >> You can load it with: >> >> Gofer new >> squeaksource: 'Famix2Importer'; >> package: 'Famix2Importer'; >> load. >> >> A menu item is available in MoosePanel menu. >> You can try it and mail us if you have some bugs. >> >> Cheers, >> Jannik and Cyrille. >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow." >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> <LAN sample model-3.famix2.mse>_______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > ---------------------------- > Johan Brichau > [hidden email] > > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev Johan Brichau [hidden email] _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
The problem come from the method FAMIXMethod >> kind: . In that method, a test is made to be sure the value affected correspond to list of kind 'allowed'. In that list, 'abstract' is not present (because it is no more used in famix3 I think). therefore , an error occure. For the moment, I had 'abstract' to this list of 'allowed' values. You should have this change by loading the last version of moose.
2010/2/16 Johan Brichau <[hidden email]> now with my attachment... (sorry) _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Famix2MSE importer Available in PharoMoose
|
|
Hi,
kind is only describes a method to be #setter #getter #constant or #constructor (these are mutually exclusive kinds). isAbstract is handled via the modifiers property which allows a collection of values like #isAbstract, or #isPublic. Cheers, Doru On 16 Feb 2010, at 21:45, Cyrille Delaunay wrote: > The problem come from the method FAMIXMethod >> kind: . In that > method, a test is made to be sure the value affected correspond to > list of kind 'allowed'. In that list, 'abstract' is not present > (because it is no more used in famix3 I think). therefore , an error > occure. For the moment, I had 'abstract' to this list of 'allowed' > values. You should have this change by loading the last version of > moose. > > 2010/2/16 Johan Brichau <[hidden email]> > now with my attachment... (sorry) > > > > > On 16 Feb 2010, at 20:50, Johan Brichau wrote: > > > Hi guys, > > > > very cool! > > (Doru: sorry for not responding earlier. I only noticed your reply > now) > > > > I just tried the attached mse file and got an error when the > 'kind' of a method was being set to 'abstract'. > > > > I'm trying to figure out how I can help to complete this. My first > guess was to edit the MethodAttributesTraduction dictionary > initialization in the FM2TradInit method to correct that. However, > what can the 'kind' be in a Famix2 file? Since Famix3 has the same > 'kind' attribute, I guess that only the value 'abstract' should no > longer be in there, right? Do you have an example in the converter > where that already occurs? > > > > cheers > > Johan > > > > On 16 Feb 2010, at 12:44, Cyrille Delaunay wrote: > > > >> Hello, > >> I join an example that works for me. But I think the problem > could come from the head of your files, because I'm really not sure > about how does a famix2mse file begin with. Can you send me your > files ? > >> > >> 2010/2/16 Tudor Girba <[hidden email]> > >> Nice initiative! > >> > >> However, I could not make it load any of my case studies. I get > syntax error. Could you provide an example that works? > >> > >> Cheers, > >> Doru > >> > >> > >> > >> On 16 Feb 2010, at 12:24, Simon Denier wrote: > >> > >> > >> On 16 févr. 2010, at 11:06, Laval Jannik wrote: > >> > >> Hi all, > >> > >> With Cyrille we work on a Famix2MseImporter in Pharo Famix3. > >> > >> It is a hack, in two parts: > >> First, we place a script between the parser and the MooseElement > creation. So this script switches elements of Famix2 to Famix3. For > example, a FAMIX.InheritanceDefinition in the Famix2Mse become a > FamixInheritance in Famix3. > >> > >> The other part of the script appears after the mooseModel > creation. In Famix3, there are FamixAccess and FamixReference. But > in Famix2, there is only FamixAccess. > >> FamixReference is for a target with type FamixClass. But, when > the parser works, it is not easily possible to know the type of an > attribute. So, to do it easy, when the MooseModel is created, we > check all accesses and test if the target is a FamixClass. If true, > the script change the link in a FamixReference. > >> > >> Now, we have three elements with no possible switch: > >> - there is no FAMIXGlobalVariable>>declaredType in Famix2. > >> - in Famix3, FAMIXInvocation>>receivingVariable has disappeared. > >> > >> I think this is replaced by FAMIXInvocation>>receiver > >> > >> - in Famix3, FAMIXParameter>>position has disappeared. > >> > >> The meta-informations in Famix2Mse are not taken account. > >> > >> Finally, this script is a hack, the aim is to provide a solution > for people who want to come to Pharo-Moose. > >> > >> You can load it with: > >> > >> Gofer new > >> squeaksource: 'Famix2Importer'; > >> package: 'Famix2Importer'; > >> load. > >> > >> A menu item is available in MoosePanel menu. > >> You can try it and mail us if you have some bugs. > >> > >> Cheers, > >> Jannik and Cyrille. > >> > >> > >> _______________________________________________ > >> Moose-dev mailing list > >> [hidden email] > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > >> -- > >> Simon > >> > >> > >> > >> > >> _______________________________________________ > >> Moose-dev mailing list > >> [hidden email] > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > >> -- > >> www.tudorgirba.com > >> > >> "Every thing has its own flow." > >> > >> > >> > >> > >> > >> _______________________________________________ > >> Moose-dev mailing list > >> [hidden email] > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > >> <LAN sample > model-3.famix2.mse>_______________________________________________ > >> Moose-dev mailing list > >> [hidden email] > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > ---------------------------- > > Johan Brichau > > [hidden email] > > > > > > > > > > > > _______________________________________________ > > Moose-dev mailing list > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > ---------------------------- > Johan Brichau > [hidden email] > > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Reasonable is what we are accustomed with." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Famix2MSE importer Available in PharoMoose
|
|
In reply to this post by cdelaunay
Hi Cyrill,
Should it not be added to the modifiers list? (I noticed that is where #isAbstract is putting it) ? If the loaded model is not a correct model, it's not really a good idea. Or am I seeing that wrong? On 16 Feb 2010, at 21:45, Cyrille Delaunay wrote: > The problem come from the method FAMIXMethod >> kind: . In that method, a test is made to be sure the value affected correspond to list of kind 'allowed'. In that list, 'abstract' is not present (because it is no more used in famix3 I think). therefore , an error occure. For the moment, I had 'abstract' to this list of 'allowed' values. You should have this change by loading the last version of moose. > > 2010/2/16 Johan Brichau <[hidden email]> > now with my attachment... (sorry) > > > > > On 16 Feb 2010, at 20:50, Johan Brichau wrote: > > > Hi guys, > > > > very cool! > > (Doru: sorry for not responding earlier. I only noticed your reply now) > > > > I just tried the attached mse file and got an error when the 'kind' of a method was being set to 'abstract'. > > > > I'm trying to figure out how I can help to complete this. My first guess was to edit the MethodAttributesTraduction dictionary initialization in the FM2TradInit method to correct that. However, what can the 'kind' be in a Famix2 file? Since Famix3 has the same 'kind' attribute, I guess that only the value 'abstract' should no longer be in there, right? Do you have an example in the converter where that already occurs? > > > > cheers > > Johan > > > > On 16 Feb 2010, at 12:44, Cyrille Delaunay wrote: > > > >> Hello, > >> I join an example that works for me. But I think the problem could come from the head of your files, because I'm really not sure about how does a famix2mse file begin with. Can you send me your files ? > >> > >> 2010/2/16 Tudor Girba <[hidden email]> > >> Nice initiative! > >> > >> However, I could not make it load any of my case studies. I get syntax error. Could you provide an example that works? > >> > >> Cheers, > >> Doru > >> > >> > >> > >> On 16 Feb 2010, at 12:24, Simon Denier wrote: > >> > >> > >> On 16 févr. 2010, at 11:06, Laval Jannik wrote: > >> > >> Hi all, > >> > >> With Cyrille we work on a Famix2MseImporter in Pharo Famix3. > >> > >> It is a hack, in two parts: > >> First, we place a script between the parser and the MooseElement creation. So this script switches elements of Famix2 to Famix3. For example, a FAMIX.InheritanceDefinition in the Famix2Mse become a FamixInheritance in Famix3. > >> > >> The other part of the script appears after the mooseModel creation. In Famix3, there are FamixAccess and FamixReference. But in Famix2, there is only FamixAccess. > >> FamixReference is for a target with type FamixClass. But, when the parser works, it is not easily possible to know the type of an attribute. So, to do it easy, when the MooseModel is created, we check all accesses and test if the target is a FamixClass. If true, the script change the link in a FamixReference. > >> > >> Now, we have three elements with no possible switch: > >> - there is no FAMIXGlobalVariable>>declaredType in Famix2. > >> - in Famix3, FAMIXInvocation>>receivingVariable has disappeared. > >> > >> I think this is replaced by FAMIXInvocation>>receiver > >> > >> - in Famix3, FAMIXParameter>>position has disappeared. > >> > >> The meta-informations in Famix2Mse are not taken account. > >> > >> Finally, this script is a hack, the aim is to provide a solution for people who want to come to Pharo-Moose. > >> > >> You can load it with: > >> > >> Gofer new > >> squeaksource: 'Famix2Importer'; > >> package: 'Famix2Importer'; > >> load. > >> > >> A menu item is available in MoosePanel menu. > >> You can try it and mail us if you have some bugs. > >> > >> Cheers, > >> Jannik and Cyrille. > >> > >> > >> _______________________________________________ > >> Moose-dev mailing list > >> [hidden email] > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > >> -- > >> Simon > >> > >> > >> > >> > >> _______________________________________________ > >> Moose-dev mailing list > >> [hidden email] > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > >> -- > >> www.tudorgirba.com > >> > >> "Every thing has its own flow." > >> > >> > >> > >> > >> > >> _______________________________________________ > >> Moose-dev mailing list > >> [hidden email] > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > >> <LAN sample model-3.famix2.mse>_______________________________________________ > >> Moose-dev mailing list > >> [hidden email] > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > ---------------------------- > > Johan Brichau > > [hidden email] > > > > > > > > > > > > _______________________________________________ > > Moose-dev mailing list > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > ---------------------------- > Johan Brichau > [hidden email] > > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev ---------------------------- Johan Brichau [hidden email] _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
I guess it should:) I will have a look at that tomorow.
2010/2/16 Johan Brichau <[hidden email]> Hi Cyrill, _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Famix2MSE importer Available in PharoMoose
|
|
Cyrille,
I can help :-) It appears such a situation (where the translation depends on the value) did not occur yet in the importer, right? Otherwise, I would take a look at that case and transpose that solution to this instance. On 16 Feb 2010, at 22:22, Cyrille Delaunay wrote: > I guess it should:) I will have a look at that tomorow. > > 2010/2/16 Johan Brichau <[hidden email]> > Hi Cyrill, > > Should it not be added to the modifiers list? (I noticed that is where #isAbstract is putting it) ? > > If the loaded model is not a correct model, it's not really a good idea. Or am I seeing that wrong? > > On 16 Feb 2010, at 21:45, Cyrille Delaunay wrote: > > > The problem come from the method FAMIXMethod >> kind: . In that method, a test is made to be sure the value affected correspond to list of kind 'allowed'. In that list, 'abstract' is not present (because it is no more used in famix3 I think). therefore , an error occure. For the moment, I had 'abstract' to this list of 'allowed' values. You should have this change by loading the last version of moose. > > > > 2010/2/16 Johan Brichau <[hidden email]> > > now with my attachment... (sorry) > > > > > > > > > > On 16 Feb 2010, at 20:50, Johan Brichau wrote: > > > > > Hi guys, > > > > > > very cool! > > > (Doru: sorry for not responding earlier. I only noticed your reply now) > > > > > > I just tried the attached mse file and got an error when the 'kind' of a method was being set to 'abstract'. > > > > > > I'm trying to figure out how I can help to complete this. My first guess was to edit the MethodAttributesTraduction dictionary initialization in the FM2TradInit method to correct that. However, what can the 'kind' be in a Famix2 file? Since Famix3 has the same 'kind' attribute, I guess that only the value 'abstract' should no longer be in there, right? Do you have an example in the converter where that already occurs? > > > > > > cheers > > > Johan > > > > > > On 16 Feb 2010, at 12:44, Cyrille Delaunay wrote: > > > > > >> Hello, > > >> I join an example that works for me. But I think the problem could come from the head of your files, because I'm really not sure about how does a famix2mse file begin with. Can you send me your files ? > > >> > > >> 2010/2/16 Tudor Girba <[hidden email]> > > >> Nice initiative! > > >> > > >> However, I could not make it load any of my case studies. I get syntax error. Could you provide an example that works? > > >> > > >> Cheers, > > >> Doru > > >> > > >> > > >> > > >> On 16 Feb 2010, at 12:24, Simon Denier wrote: > > >> > > >> > > >> On 16 févr. 2010, at 11:06, Laval Jannik wrote: > > >> > > >> Hi all, > > >> > > >> With Cyrille we work on a Famix2MseImporter in Pharo Famix3. > > >> > > >> It is a hack, in two parts: > > >> First, we place a script between the parser and the MooseElement creation. So this script switches elements of Famix2 to Famix3. For example, a FAMIX.InheritanceDefinition in the Famix2Mse become a FamixInheritance in Famix3. > > >> > > >> The other part of the script appears after the mooseModel creation. In Famix3, there are FamixAccess and FamixReference. But in Famix2, there is only FamixAccess. > > >> FamixReference is for a target with type FamixClass. But, when the parser works, it is not easily possible to know the type of an attribute. So, to do it easy, when the MooseModel is created, we check all accesses and test if the target is a FamixClass. If true, the script change the link in a FamixReference. > > >> > > >> Now, we have three elements with no possible switch: > > >> - there is no FAMIXGlobalVariable>>declaredType in Famix2. > > >> - in Famix3, FAMIXInvocation>>receivingVariable has disappeared. > > >> > > >> I think this is replaced by FAMIXInvocation>>receiver > > >> > > >> - in Famix3, FAMIXParameter>>position has disappeared. > > >> > > >> The meta-informations in Famix2Mse are not taken account. > > >> > > >> Finally, this script is a hack, the aim is to provide a solution for people who want to come to Pharo-Moose. > > >> > > >> You can load it with: > > >> > > >> Gofer new > > >> squeaksource: 'Famix2Importer'; > > >> package: 'Famix2Importer'; > > >> load. > > >> > > >> A menu item is available in MoosePanel menu. > > >> You can try it and mail us if you have some bugs. > > >> > > >> Cheers, > > >> Jannik and Cyrille. > > >> > > >> > > >> _______________________________________________ > > >> Moose-dev mailing list > > >> [hidden email] > > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > >> > > >> -- > > >> Simon > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> Moose-dev mailing list > > >> [hidden email] > > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > >> > > >> -- > > >> www.tudorgirba.com > > >> > > >> "Every thing has its own flow." > > >> > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> Moose-dev mailing list > > >> [hidden email] > > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > >> > > >> <LAN sample model-3.famix2.mse>_______________________________________________ > > >> Moose-dev mailing list > > >> [hidden email] > > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > > ---------------------------- > > > Johan Brichau > > > [hidden email] > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Moose-dev mailing list > > > [hidden email] > > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > ---------------------------- > > Johan Brichau > > [hidden email] > > > > > > > > > > > > _______________________________________________ > > Moose-dev mailing list > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > > _______________________________________________ > > Moose-dev mailing list > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > ---------------------------- > Johan Brichau > [hidden email] > > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev ---------------------------- Johan Brichau [hidden email] _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Famix2MSE importer Available in PharoMoose
|
|
Hi Johan,
We will be glad of your help. For now the importer is a pre-alpha thing :) We test it on some models but we don't know all details of Famix2Mse. Before a real use, we need feedback to know if we do not forget something. Thank you for your feedback, we will see it with Cyrille today. Cheers, Jannik On Feb 16, 2010, at 22:25 , Johan Brichau wrote: > Cyrille, > > I can help :-) > It appears such a situation (where the translation depends on the value) did not occur yet in the importer, right? Otherwise, I would take a look at that case and transpose that solution to this instance. > > > > On 16 Feb 2010, at 22:22, Cyrille Delaunay wrote: > >> I guess it should:) I will have a look at that tomorow. >> >> 2010/2/16 Johan Brichau <[hidden email]> >> Hi Cyrill, >> >> Should it not be added to the modifiers list? (I noticed that is where #isAbstract is putting it) ? >> >> If the loaded model is not a correct model, it's not really a good idea. Or am I seeing that wrong? >> >> On 16 Feb 2010, at 21:45, Cyrille Delaunay wrote: >> >>> The problem come from the method FAMIXMethod >> kind: . In that method, a test is made to be sure the value affected correspond to list of kind 'allowed'. In that list, 'abstract' is not present (because it is no more used in famix3 I think). therefore , an error occure. For the moment, I had 'abstract' to this list of 'allowed' values. You should have this change by loading the last version of moose. >>> >>> 2010/2/16 Johan Brichau <[hidden email]> >>> now with my attachment... (sorry) >>> >>> >>> >>> >>> On 16 Feb 2010, at 20:50, Johan Brichau wrote: >>> >>>> Hi guys, >>>> >>>> very cool! >>>> (Doru: sorry for not responding earlier. I only noticed your reply now) >>>> >>>> I just tried the attached mse file and got an error when the 'kind' of a method was being set to 'abstract'. >>>> >>>> I'm trying to figure out how I can help to complete this. My first guess was to edit the MethodAttributesTraduction dictionary initialization in the FM2TradInit method to correct that. However, what can the 'kind' be in a Famix2 file? Since Famix3 has the same 'kind' attribute, I guess that only the value 'abstract' should no longer be in there, right? Do you have an example in the converter where that already occurs? >>>> >>>> cheers >>>> Johan >>>> >>>> On 16 Feb 2010, at 12:44, Cyrille Delaunay wrote: >>>> >>>>> Hello, >>>>> I join an example that works for me. But I think the problem could come from the head of your files, because I'm really not sure about how does a famix2mse file begin with. Can you send me your files ? >>>>> >>>>> 2010/2/16 Tudor Girba <[hidden email]> >>>>> Nice initiative! >>>>> >>>>> However, I could not make it load any of my case studies. I get syntax error. Could you provide an example that works? >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> >>>>> On 16 Feb 2010, at 12:24, Simon Denier wrote: >>>>> >>>>> >>>>> On 16 févr. 2010, at 11:06, Laval Jannik wrote: >>>>> >>>>> Hi all, >>>>> >>>>> With Cyrille we work on a Famix2MseImporter in Pharo Famix3. >>>>> >>>>> It is a hack, in two parts: >>>>> First, we place a script between the parser and the MooseElement creation. So this script switches elements of Famix2 to Famix3. For example, a FAMIX.InheritanceDefinition in the Famix2Mse become a FamixInheritance in Famix3. >>>>> >>>>> The other part of the script appears after the mooseModel creation. In Famix3, there are FamixAccess and FamixReference. But in Famix2, there is only FamixAccess. >>>>> FamixReference is for a target with type FamixClass. But, when the parser works, it is not easily possible to know the type of an attribute. So, to do it easy, when the MooseModel is created, we check all accesses and test if the target is a FamixClass. If true, the script change the link in a FamixReference. >>>>> >>>>> Now, we have three elements with no possible switch: >>>>> - there is no FAMIXGlobalVariable>>declaredType in Famix2. >>>>> - in Famix3, FAMIXInvocation>>receivingVariable has disappeared. >>>>> >>>>> I think this is replaced by FAMIXInvocation>>receiver >>>>> >>>>> - in Famix3, FAMIXParameter>>position has disappeared. >>>>> >>>>> The meta-informations in Famix2Mse are not taken account. >>>>> >>>>> Finally, this script is a hack, the aim is to provide a solution for people who want to come to Pharo-Moose. >>>>> >>>>> You can load it with: >>>>> >>>>> Gofer new >>>>> squeaksource: 'Famix2Importer'; >>>>> package: 'Famix2Importer'; >>>>> load. >>>>> >>>>> A menu item is available in MoosePanel menu. >>>>> You can try it and mail us if you have some bugs. >>>>> >>>>> Cheers, >>>>> Jannik and Cyrille. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> [hidden email] >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> Simon >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> [hidden email] >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Every thing has its own flow." >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> [hidden email] >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> <LAN sample model-3.famix2.mse>_______________________________________________ >>>>> Moose-dev mailing list >>>>> [hidden email] >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> ---------------------------- >>>> Johan Brichau >>>> [hidden email] >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> ---------------------------- >>> Johan Brichau >>> [hidden email] >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> ---------------------------- >> Johan Brichau >> [hidden email] >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > ---------------------------- > Johan Brichau > [hidden email] > > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Johan, I tryed to import your file. And I find a new problem:
In Famix3, a FAMIXAccess can be made to any FAMIXStructuralEntity (GlobalVariable, ImplicitVariable, LocalVariable, Parameter , UnknownVariable, Attribute). Those classes are declared as 'variable' of the FAMIXAccess.then, they have opposite link to the Access by the method FAMIXStructuralEntity>> incomingAccesses.
Now, in Famix2 , a FAMIXNamspace can be declared as 'variable' of a FAMIXAccess. But the class FAMIXNamespace does't provide the method 'incomingAccesses', and an error occure.
Have you any idea about how to solve this problem?
2010/2/17 Laval Jannik <[hidden email]> Hi Johan, _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Famix2MSE importer Available in PharoMoose
|
|
On 17 févr. 2010, at 11:04, Cyrille Delaunay wrote: Johan, I tryed to import your file. And I find a new problem: Such access should be converted to FamixReference in Famix3 - I think.
-- Simon _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Ok, so this is what I have done for the moment:
- I added incomingAccesses to FAMIXNamspace as an extension of Famix2Importer. - The importer first create all those accesses made to namespace. - Once the list of elements generated, I iterate over them and replace those accesses into references.
What do you think ? Johan, now the importer is working for your file . ps: I also changed the kind 'abstract' of a method to be added as #isAbstract to the modier list (I did it in the same way than for those FAMIXNamespace's accesses => references)
2010/2/17 Simon Denier <[hidden email]>
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Famix2MSE importer Available in PharoMoose
|
|
Hi guys,
That's cool. I will try also with some more models and try to fix problems as they occur too. I also noticed the exporter in VW is not including the #LOC metric. Moose in VW seems to expect that Smalltalk models remain in the image to derive any additional properties on the fly. Does there exist a way to 'complete' such a model and export that information too? Otherwise, I try to implement that myself. Doru? :-) On 17 Feb 2010, at 13:40, Cyrille Delaunay wrote: > Ok, so this is what I have done for the moment: > - I added incomingAccesses to FAMIXNamspace as an extension of Famix2Importer. > - The importer first create all those accesses made to namespace. > - Once the list of elements generated, I iterate over them and replace those accesses into references. > > What do you think ? > Johan, now the importer is working for your file . > > ps: I also changed the kind 'abstract' of a method to be added as #isAbstract to the modier list (I did it in the same way than for those FAMIXNamespace's accesses => references) > > > 2010/2/17 Simon Denier <[hidden email]> > > On 17 févr. 2010, at 11:04, Cyrille Delaunay wrote: > >> Johan, I tryed to import your file. And I find a new problem: >> >> In Famix3, a FAMIXAccess can be made to any FAMIXStructuralEntity (GlobalVariable, ImplicitVariable, LocalVariable, Parameter , UnknownVariable, Attribute). Those classes are declared as 'variable' of the FAMIXAccess.then, they have opposite link to the Access by the method FAMIXStructuralEntity>> incomingAccesses. >> >> Now, in Famix2 , a FAMIXNamspace can be declared as 'variable' of a FAMIXAccess. But the class FAMIXNamespace does't provide the method 'incomingAccesses', and an error occure. > > > Such access should be converted to FamixReference in Famix3 - I think. > > >> >> >> >> Have you any idea about how to solve this problem? >> >> 2010/2/17 Laval Jannik <[hidden email]> >> Hi Johan, >> >> We will be glad of your help. >> >> For now the importer is a pre-alpha thing :) >> We test it on some models but we don't know all details of Famix2Mse. >> >> Before a real use, we need feedback to know if we do not forget something. >> Thank you for your feedback, we will see it with Cyrille today. >> >> Cheers, >> Jannik >> >> On Feb 16, 2010, at 22:25 , Johan Brichau wrote: >> >> > Cyrille, >> > >> > I can help :-) >> > It appears such a situation (where the translation depends on the value) did not occur yet in the importer, right? Otherwise, I would take a look at that case and transpose that solution to this instance. >> > >> > >> > >> > On 16 Feb 2010, at 22:22, Cyrille Delaunay wrote: >> > >> >> I guess it should:) I will have a look at that tomorow. >> >> >> >> 2010/2/16 Johan Brichau <[hidden email]> >> >> Hi Cyrill, >> >> >> >> Should it not be added to the modifiers list? (I noticed that is where #isAbstract is putting it) ? >> >> >> >> If the loaded model is not a correct model, it's not really a good idea. Or am I seeing that wrong? >> >> >> >> On 16 Feb 2010, at 21:45, Cyrille Delaunay wrote: >> >> >> >>> The problem come from the method FAMIXMethod >> kind: . In that method, a test is made to be sure the value affected correspond to list of kind 'allowed'. In that list, 'abstract' is not present (because it is no more used in famix3 I think). therefore , an error occure. For the moment, I had 'abstract' to this list of 'allowed' values. You should have this change by loading the last version of moose. >> >>> >> >>> 2010/2/16 Johan Brichau <[hidden email]> >> >>> now with my attachment... (sorry) >> >>> >> >>> >> >>> >> >>> >> >>> On 16 Feb 2010, at 20:50, Johan Brichau wrote: >> >>> >> >>>> Hi guys, >> >>>> >> >>>> very cool! >> >>>> (Doru: sorry for not responding earlier. I only noticed your reply now) >> >>>> >> >>>> I just tried the attached mse file and got an error when the 'kind' of a method was being set to 'abstract'. >> >>>> >> >>>> I'm trying to figure out how I can help to complete this. My first guess was to edit the MethodAttributesTraduction dictionary initialization in the FM2TradInit method to correct that. However, what can the 'kind' be in a Famix2 file? Since Famix3 has the same 'kind' attribute, I guess that only the value 'abstract' should no longer be in there, right? Do you have an example in the converter where that already occurs? >> >>>> >> >>>> cheers >> >>>> Johan >> >>>> >> >>>> On 16 Feb 2010, at 12:44, Cyrille Delaunay wrote: >> >>>> >> >>>>> Hello, >> >>>>> I join an example that works for me. But I think the problem could come from the head of your files, because I'm really not sure about how does a famix2mse file begin with. Can you send me your files ? >> >>>>> >> >>>>> 2010/2/16 Tudor Girba <[hidden email]> >> >>>>> Nice initiative! >> >>>>> >> >>>>> However, I could not make it load any of my case studies. I get syntax error. Could you provide an example that works? >> >>>>> >> >>>>> Cheers, >> >>>>> Doru >> >>>>> >> >>>>> >> >>>>> >> >>>>> On 16 Feb 2010, at 12:24, Simon Denier wrote: >> >>>>> >> >>>>> >> >>>>> On 16 févr. 2010, at 11:06, Laval Jannik wrote: >> >>>>> >> >>>>> Hi all, >> >>>>> >> >>>>> With Cyrille we work on a Famix2MseImporter in Pharo Famix3. >> >>>>> >> >>>>> It is a hack, in two parts: >> >>>>> First, we place a script between the parser and the MooseElement creation. So this script switches elements of Famix2 to Famix3. For example, a FAMIX.InheritanceDefinition in the Famix2Mse become a FamixInheritance in Famix3. >> >>>>> >> >>>>> The other part of the script appears after the mooseModel creation. In Famix3, there are FamixAccess and FamixReference. But in Famix2, there is only FamixAccess. >> >>>>> FamixReference is for a target with type FamixClass. But, when the parser works, it is not easily possible to know the type of an attribute. So, to do it easy, when the MooseModel is created, we check all accesses and test if the target is a FamixClass. If true, the script change the link in a FamixReference. >> >>>>> >> >>>>> Now, we have three elements with no possible switch: >> >>>>> - there is no FAMIXGlobalVariable>>declaredType in Famix2. >> >>>>> - in Famix3, FAMIXInvocation>>receivingVariable has disappeared. >> >>>>> >> >>>>> I think this is replaced by FAMIXInvocation>>receiver >> >>>>> >> >>>>> - in Famix3, FAMIXParameter>>position has disappeared. >> >>>>> >> >>>>> The meta-informations in Famix2Mse are not taken account. >> >>>>> >> >>>>> Finally, this script is a hack, the aim is to provide a solution for people who want to come to Pharo-Moose. >> >>>>> >> >>>>> You can load it with: >> >>>>> >> >>>>> Gofer new >> >>>>> squeaksource: 'Famix2Importer'; >> >>>>> package: 'Famix2Importer'; >> >>>>> load. >> >>>>> >> >>>>> A menu item is available in MoosePanel menu. >> >>>>> You can try it and mail us if you have some bugs. >> >>>>> >> >>>>> Cheers, >> >>>>> Jannik and Cyrille. >> >>>>> >> >>>>> >> >>>>> _______________________________________________ >> >>>>> Moose-dev mailing list >> >>>>> [hidden email] >> >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >>>>> >> >>>>> -- >> >>>>> Simon >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> _______________________________________________ >> >>>>> Moose-dev mailing list >> >>>>> [hidden email] >> >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >>>>> >> >>>>> -- >> >>>>> www.tudorgirba.com >> >>>>> >> >>>>> "Every thing has its own flow." >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> _______________________________________________ >> >>>>> Moose-dev mailing list >> >>>>> [hidden email] >> >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >>>>> >> >>>>> <LAN sample model-3.famix2.mse>_______________________________________________ >> >>>>> Moose-dev mailing list >> >>>>> [hidden email] >> >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >>>> >> >>>> ---------------------------- >> >>>> Johan Brichau >> >>>> [hidden email] >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> Moose-dev mailing list >> >>>> [hidden email] >> >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >>> >> >>> ---------------------------- >> >>> Johan Brichau >> >>> [hidden email] >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> Moose-dev mailing list >> >>> [hidden email] >> >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >>> >> >>> >> >>> _______________________________________________ >> >>> Moose-dev mailing list >> >>> [hidden email] >> >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> ---------------------------- >> >> Johan Brichau >> >> [hidden email] >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> Moose-dev mailing list >> >> [hidden email] >> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> _______________________________________________ >> >> Moose-dev mailing list >> >> [hidden email] >> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > >> > ---------------------------- >> > Johan Brichau >> > [hidden email] >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Moose-dev mailing list >> > [hidden email] >> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev ---------------------------- Johan Brichau [hidden email] _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Famix2MSE importer Available in PharoMoose
|
|
Hi Johan,
The reason is that in VW properties like LOC are only described for the UI with pragmas. If you want them stored in MSE you have to declare them on the class side as an attribute. Cheers, Doru On 17 Feb 2010, at 16:03, Johan Brichau wrote: > Hi guys, > > That's cool. I will try also with some more models and try to fix > problems as they occur too. > > I also noticed the exporter in VW is not including the #LOC metric. > Moose in VW seems to expect that Smalltalk models remain in the > image to derive any additional properties on the fly. Does there > exist a way to 'complete' such a model and export that information > too? Otherwise, I try to implement that myself. > Doru? :-) > > > On 17 Feb 2010, at 13:40, Cyrille Delaunay wrote: > >> Ok, so this is what I have done for the moment: >> - I added incomingAccesses to FAMIXNamspace as an extension of >> Famix2Importer. >> - The importer first create all those accesses made to namespace. >> - Once the list of elements generated, I iterate over them and >> replace those accesses into references. >> >> What do you think ? >> Johan, now the importer is working for your file . >> >> ps: I also changed the kind 'abstract' of a method to be added as >> #isAbstract to the modier list (I did it in the same way than for >> those FAMIXNamespace's accesses => references) >> >> >> 2010/2/17 Simon Denier <[hidden email]> >> >> On 17 févr. 2010, at 11:04, Cyrille Delaunay wrote: >> >>> Johan, I tryed to import your file. And I find a new problem: >>> >>> In Famix3, a FAMIXAccess can be made to any FAMIXStructuralEntity >>> (GlobalVariable, ImplicitVariable, LocalVariable, Parameter , >>> UnknownVariable, Attribute). Those classes are declared as >>> 'variable' of the FAMIXAccess.then, they have opposite link to the >>> Access by the method FAMIXStructuralEntity>> incomingAccesses. >>> >>> Now, in Famix2 , a FAMIXNamspace can be declared as 'variable' of >>> a FAMIXAccess. But the class FAMIXNamespace does't provide the >>> method 'incomingAccesses', and an error occure. >> >> >> Such access should be converted to FamixReference in Famix3 - I >> think. >> >> >>> >>> >>> >>> Have you any idea about how to solve this problem? >>> >>> 2010/2/17 Laval Jannik <[hidden email]> >>> Hi Johan, >>> >>> We will be glad of your help. >>> >>> For now the importer is a pre-alpha thing :) >>> We test it on some models but we don't know all details of >>> Famix2Mse. >>> >>> Before a real use, we need feedback to know if we do not forget >>> something. >>> Thank you for your feedback, we will see it with Cyrille today. >>> >>> Cheers, >>> Jannik >>> >>> On Feb 16, 2010, at 22:25 , Johan Brichau wrote: >>> >>>> Cyrille, >>>> >>>> I can help :-) >>>> It appears such a situation (where the translation depends on the >>>> value) did not occur yet in the importer, right? Otherwise, I >>>> would take a look at that case and transpose that solution to >>>> this instance. >>>> >>>> >>>> >>>> On 16 Feb 2010, at 22:22, Cyrille Delaunay wrote: >>>> >>>>> I guess it should:) I will have a look at that tomorow. >>>>> >>>>> 2010/2/16 Johan Brichau <[hidden email]> >>>>> Hi Cyrill, >>>>> >>>>> Should it not be added to the modifiers list? (I noticed that is >>>>> where #isAbstract is putting it) ? >>>>> >>>>> If the loaded model is not a correct model, it's not really a >>>>> good idea. Or am I seeing that wrong? >>>>> >>>>> On 16 Feb 2010, at 21:45, Cyrille Delaunay wrote: >>>>> >>>>>> The problem come from the method FAMIXMethod >> kind: . In that >>>>>> method, a test is made to be sure the value affected correspond >>>>>> to list of kind 'allowed'. In that list, 'abstract' is not >>>>>> present (because it is no more used in famix3 I think). >>>>>> therefore , an error occure. For the moment, I had 'abstract' >>>>>> to this list of 'allowed' values. You should have this change >>>>>> by loading the last version of moose. >>>>>> >>>>>> 2010/2/16 Johan Brichau <[hidden email]> >>>>>> now with my attachment... (sorry) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 16 Feb 2010, at 20:50, Johan Brichau wrote: >>>>>> >>>>>>> Hi guys, >>>>>>> >>>>>>> very cool! >>>>>>> (Doru: sorry for not responding earlier. I only noticed your >>>>>>> reply now) >>>>>>> >>>>>>> I just tried the attached mse file and got an error when the >>>>>>> 'kind' of a method was being set to 'abstract'. >>>>>>> >>>>>>> I'm trying to figure out how I can help to complete this. My >>>>>>> first guess was to edit the MethodAttributesTraduction >>>>>>> dictionary initialization in the FM2TradInit method to correct >>>>>>> that. However, what can the 'kind' be in a Famix2 file? Since >>>>>>> Famix3 has the same 'kind' attribute, I guess that only the >>>>>>> value 'abstract' should no longer be in there, right? Do you >>>>>>> have an example in the converter where that already occurs? >>>>>>> >>>>>>> cheers >>>>>>> Johan >>>>>>> >>>>>>> On 16 Feb 2010, at 12:44, Cyrille Delaunay wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> I join an example that works for me. But I think the problem >>>>>>>> could come from the head of your files, because I'm really >>>>>>>> not sure about how does a famix2mse file begin with. Can you >>>>>>>> send me your files ? >>>>>>>> >>>>>>>> 2010/2/16 Tudor Girba <[hidden email]> >>>>>>>> Nice initiative! >>>>>>>> >>>>>>>> However, I could not make it load any of my case studies. I >>>>>>>> get syntax error. Could you provide an example that works? >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Doru >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 16 Feb 2010, at 12:24, Simon Denier wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 16 févr. 2010, at 11:06, Laval Jannik wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> With Cyrille we work on a Famix2MseImporter in Pharo Famix3. >>>>>>>> >>>>>>>> It is a hack, in two parts: >>>>>>>> First, we place a script between the parser and the >>>>>>>> MooseElement creation. So this script switches elements of >>>>>>>> Famix2 to Famix3. For example, a FAMIX.InheritanceDefinition >>>>>>>> in the Famix2Mse become a FamixInheritance in Famix3. >>>>>>>> >>>>>>>> The other part of the script appears after the mooseModel >>>>>>>> creation. In Famix3, there are FamixAccess and >>>>>>>> FamixReference. But in Famix2, there is only FamixAccess. >>>>>>>> FamixReference is for a target with type FamixClass. But, >>>>>>>> when the parser works, it is not easily possible to know the >>>>>>>> type of an attribute. So, to do it easy, when the MooseModel >>>>>>>> is created, we check all accesses and test if the target is a >>>>>>>> FamixClass. If true, the script change the link in a >>>>>>>> FamixReference. >>>>>>>> >>>>>>>> Now, we have three elements with no possible switch: >>>>>>>> - there is no FAMIXGlobalVariable>>declaredType in Famix2. >>>>>>>> - in Famix3, FAMIXInvocation>>receivingVariable has >>>>>>>> disappeared. >>>>>>>> >>>>>>>> I think this is replaced by FAMIXInvocation>>receiver >>>>>>>> >>>>>>>> - in Famix3, FAMIXParameter>>position has disappeared. >>>>>>>> >>>>>>>> The meta-informations in Famix2Mse are not taken account. >>>>>>>> >>>>>>>> Finally, this script is a hack, the aim is to provide a >>>>>>>> solution for people who want to come to Pharo-Moose. >>>>>>>> >>>>>>>> You can load it with: >>>>>>>> >>>>>>>> Gofer new >>>>>>>> squeaksource: 'Famix2Importer'; >>>>>>>> package: 'Famix2Importer'; >>>>>>>> load. >>>>>>>> >>>>>>>> A menu item is available in MoosePanel menu. >>>>>>>> You can try it and mail us if you have some bugs. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Jannik and Cyrille. >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Moose-dev mailing list >>>>>>>> [hidden email] >>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>> >>>>>>>> -- >>>>>>>> Simon >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Moose-dev mailing list >>>>>>>> [hidden email] >>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>> >>>>>>>> -- >>>>>>>> www.tudorgirba.com >>>>>>>> >>>>>>>> "Every thing has its own flow." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Moose-dev mailing list >>>>>>>> [hidden email] >>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>> >>>>>>>> <LAN sample >>>>>>>> model >>>>>>>> -3.famix2.mse>_______________________________________________ >>>>>>>> Moose-dev mailing list >>>>>>>> [hidden email] >>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>> >>>>>>> ---------------------------- >>>>>>> Johan Brichau >>>>>>> [hidden email] >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> [hidden email] >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> ---------------------------- >>>>>> Johan Brichau >>>>>> [hidden email] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> [hidden email] >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> [hidden email] >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> ---------------------------- >>>>> Johan Brichau >>>>> [hidden email] >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> [hidden email] >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> [hidden email] >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> ---------------------------- >>>> Johan Brichau >>>> [hidden email] >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > ---------------------------- > Johan Brichau > [hidden email] > > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Famix2MSE importer Available in PharoMoose
|
|
Thanks Doru. I will take a look at that.
It all seems to work very well now except for large models. What can you in Pharo to use more memory? I have a large model exported from VW which gives trouble importing into Pharo merely because of the size of it. One item that first seemed to help is not to convert the filestream into a readwritestream in the #importFromFamix2MSE method. I changed the method as follows: importFromFamix2MSE <menuItem: 'Import from Famix2 MSE' category: 'Import / Export'> | stream contents streamCopy | stream := UITheme builder fileOpen: 'Import model from MSE file' extensions: #('mse'). "we skip all the famix 2 specific head of file." stream upTo: $( . stream upTo: $( . stream upTo: $( . stream upTo: $( . stream next: 6. stream nextPut: $(. stream back. self name: (FileDirectory baseNameFor: stream localName). self importFromFamix2MSEStream: stream. stream close However, I later run out of memory when parsing it. Any ideas? On 17 Feb 2010, at 20:41, Tudor Girba wrote: > Hi Johan, > > The reason is that in VW properties like LOC are only described for the UI with pragmas. If you want them stored in MSE you have to declare them on the class side as an attribute. > > Cheers, > Doru > > On 17 Feb 2010, at 16:03, Johan Brichau wrote: > >> Hi guys, >> >> That's cool. I will try also with some more models and try to fix problems as they occur too. >> >> I also noticed the exporter in VW is not including the #LOC metric. Moose in VW seems to expect that Smalltalk models remain in the image to derive any additional properties on the fly. Does there exist a way to 'complete' such a model and export that information too? Otherwise, I try to implement that myself. >> Doru? :-) >> >> >> On 17 Feb 2010, at 13:40, Cyrille Delaunay wrote: >> >>> Ok, so this is what I have done for the moment: >>> - I added incomingAccesses to FAMIXNamspace as an extension of Famix2Importer. >>> - The importer first create all those accesses made to namespace. >>> - Once the list of elements generated, I iterate over them and replace those accesses into references. >>> >>> What do you think ? >>> Johan, now the importer is working for your file . >>> >>> ps: I also changed the kind 'abstract' of a method to be added as #isAbstract to the modier list (I did it in the same way than for those FAMIXNamespace's accesses => references) >>> >>> >>> 2010/2/17 Simon Denier <[hidden email]> >>> >>> On 17 févr. 2010, at 11:04, Cyrille Delaunay wrote: >>> >>>> Johan, I tryed to import your file. And I find a new problem: >>>> >>>> In Famix3, a FAMIXAccess can be made to any FAMIXStructuralEntity (GlobalVariable, ImplicitVariable, LocalVariable, Parameter , UnknownVariable, Attribute). Those classes are declared as 'variable' of the FAMIXAccess.then, they have opposite link to the Access by the method FAMIXStructuralEntity>> incomingAccesses. >>>> >>>> Now, in Famix2 , a FAMIXNamspace can be declared as 'variable' of a FAMIXAccess. But the class FAMIXNamespace does't provide the method 'incomingAccesses', and an error occure. >>> >>> >>> Such access should be converted to FamixReference in Famix3 - I think. >>> >>> >>>> >>>> >>>> >>>> Have you any idea about how to solve this problem? >>>> >>>> 2010/2/17 Laval Jannik <[hidden email]> >>>> Hi Johan, >>>> >>>> We will be glad of your help. >>>> >>>> For now the importer is a pre-alpha thing :) >>>> We test it on some models but we don't know all details of Famix2Mse. >>>> >>>> Before a real use, we need feedback to know if we do not forget something. >>>> Thank you for your feedback, we will see it with Cyrille today. >>>> >>>> Cheers, >>>> Jannik >>>> >>>> On Feb 16, 2010, at 22:25 , Johan Brichau wrote: >>>> >>>>> Cyrille, >>>>> >>>>> I can help :-) >>>>> It appears such a situation (where the translation depends on the value) did not occur yet in the importer, right? Otherwise, I would take a look at that case and transpose that solution to this instance. >>>>> >>>>> >>>>> >>>>> On 16 Feb 2010, at 22:22, Cyrille Delaunay wrote: >>>>> >>>>>> I guess it should:) I will have a look at that tomorow. >>>>>> >>>>>> 2010/2/16 Johan Brichau <[hidden email]> >>>>>> Hi Cyrill, >>>>>> >>>>>> Should it not be added to the modifiers list? (I noticed that is where #isAbstract is putting it) ? >>>>>> >>>>>> If the loaded model is not a correct model, it's not really a good idea. Or am I seeing that wrong? >>>>>> >>>>>> On 16 Feb 2010, at 21:45, Cyrille Delaunay wrote: >>>>>> >>>>>>> The problem come from the method FAMIXMethod >> kind: . In that method, a test is made to be sure the value affected correspond to list of kind 'allowed'. In that list, 'abstract' is not present (because it is no more used in famix3 I think). therefore , an error occure. For the moment, I had 'abstract' to this list of 'allowed' values. You should have this change by loading the last version of moose. >>>>>>> >>>>>>> 2010/2/16 Johan Brichau <[hidden email]> >>>>>>> now with my attachment... (sorry) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 16 Feb 2010, at 20:50, Johan Brichau wrote: >>>>>>> >>>>>>>> Hi guys, >>>>>>>> >>>>>>>> very cool! >>>>>>>> (Doru: sorry for not responding earlier. I only noticed your reply now) >>>>>>>> >>>>>>>> I just tried the attached mse file and got an error when the 'kind' of a method was being set to 'abstract'. >>>>>>>> >>>>>>>> I'm trying to figure out how I can help to complete this. My first guess was to edit the MethodAttributesTraduction dictionary initialization in the FM2TradInit method to correct that. However, what can the 'kind' be in a Famix2 file? Since Famix3 has the same 'kind' attribute, I guess that only the value 'abstract' should no longer be in there, right? Do you have an example in the converter where that already occurs? >>>>>>>> >>>>>>>> cheers >>>>>>>> Johan >>>>>>>> >>>>>>>> On 16 Feb 2010, at 12:44, Cyrille Delaunay wrote: >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> I join an example that works for me. But I think the problem could come from the head of your files, because I'm really not sure about how does a famix2mse file begin with. Can you send me your files ? >>>>>>>>> >>>>>>>>> 2010/2/16 Tudor Girba <[hidden email]> >>>>>>>>> Nice initiative! >>>>>>>>> >>>>>>>>> However, I could not make it load any of my case studies. I get syntax error. Could you provide an example that works? >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Doru >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 16 Feb 2010, at 12:24, Simon Denier wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 16 févr. 2010, at 11:06, Laval Jannik wrote: >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> With Cyrille we work on a Famix2MseImporter in Pharo Famix3. >>>>>>>>> >>>>>>>>> It is a hack, in two parts: >>>>>>>>> First, we place a script between the parser and the MooseElement creation. So this script switches elements of Famix2 to Famix3. For example, a FAMIX.InheritanceDefinition in the Famix2Mse become a FamixInheritance in Famix3. >>>>>>>>> >>>>>>>>> The other part of the script appears after the mooseModel creation. In Famix3, there are FamixAccess and FamixReference. But in Famix2, there is only FamixAccess. >>>>>>>>> FamixReference is for a target with type FamixClass. But, when the parser works, it is not easily possible to know the type of an attribute. So, to do it easy, when the MooseModel is created, we check all accesses and test if the target is a FamixClass. If true, the script change the link in a FamixReference. >>>>>>>>> >>>>>>>>> Now, we have three elements with no possible switch: >>>>>>>>> - there is no FAMIXGlobalVariable>>declaredType in Famix2. >>>>>>>>> - in Famix3, FAMIXInvocation>>receivingVariable has disappeared. >>>>>>>>> >>>>>>>>> I think this is replaced by FAMIXInvocation>>receiver >>>>>>>>> >>>>>>>>> - in Famix3, FAMIXParameter>>position has disappeared. >>>>>>>>> >>>>>>>>> The meta-informations in Famix2Mse are not taken account. >>>>>>>>> >>>>>>>>> Finally, this script is a hack, the aim is to provide a solution for people who want to come to Pharo-Moose. >>>>>>>>> >>>>>>>>> You can load it with: >>>>>>>>> >>>>>>>>> Gofer new >>>>>>>>> squeaksource: 'Famix2Importer'; >>>>>>>>> package: 'Famix2Importer'; >>>>>>>>> load. >>>>>>>>> >>>>>>>>> A menu item is available in MoosePanel menu. >>>>>>>>> You can try it and mail us if you have some bugs. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Jannik and Cyrille. >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Moose-dev mailing list >>>>>>>>> [hidden email] >>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Simon >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Moose-dev mailing list >>>>>>>>> [hidden email] >>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>>> >>>>>>>>> -- >>>>>>>>> www.tudorgirba.com >>>>>>>>> >>>>>>>>> "Every thing has its own flow." >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Moose-dev mailing list >>>>>>>>> [hidden email] >>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>>> >>>>>>>>> <LAN sample model-3.famix2.mse>_______________________________________________ >>>>>>>>> Moose-dev mailing list >>>>>>>>> [hidden email] >>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>> >>>>>>>> ---------------------------- >>>>>>>> Johan Brichau >>>>>>>> [hidden email] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Moose-dev mailing list >>>>>>>> [hidden email] >>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>> >>>>>>> ---------------------------- >>>>>>> Johan Brichau >>>>>>> [hidden email] >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> [hidden email] >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> [hidden email] >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> ---------------------------- >>>>>> Johan Brichau >>>>>> [hidden email] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> [hidden email] >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> [hidden email] >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> ---------------------------- >>>>> Johan Brichau >>>>> [hidden email] >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> [hidden email] >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> Simon >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> ---------------------------- >> Johan Brichau >> [hidden email] >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "From an abstract enough point of view, any two things are similar." > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev ---------------------------- Johan Brichau [hidden email] _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Famix2MSE importer Available in PharoMoose
|
|
Hi Johan,
When I work on big models, I run the VM with more memory: In Command line: Squeak\ 4.2.2beta1U.app/Contents/MacOS/Squeak\ VM\ Opt -memory 1500m It should work with this. Cheers, Jannik On Feb 18, 2010, at 08:12 , Johan Brichau wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |