16 Feb
2010
16 Feb
'10
11:06 a.m.
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.
16 Feb
16 Feb
12:24 p.m.
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
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
12:31 p.m.
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:
--
www.tudorgirba.com
"Every thing has its own flow."
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
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
12:44 p.m.
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 <tudor.girba(a)gmail.com>
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,
--
www.tudorgirba.com
"Every thing has its own flow."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
12:47 p.m.
New subject: Fwd: Re: Famix2MSE importer Available in PharoMoose
---------- Forwarded message ----------
From: Cyrille Delaunay <cy.delaunay(a)gmail.com>
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 <
moose-dev(a)iam.unibe.ch>
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 <tudor.girba(a)gmail.com>
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,
--
www.tudorgirba.com
"Every thing has its own flow."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
8:50 p.m.
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 <tudor.girba(a)gmail.com>
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
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
<LAN sample model-3.famix2.mse>_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
8:54 p.m.
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:
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
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 <tudor.girba(a)gmail.com>
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
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
<LAN sample model-3.famix2.mse>_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
9:45 p.m.
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 <johan.brichau(a)uclouvain.be>
now with my attachment... (sorry)
On 16 Feb 2010, at 20:50, Johan Brichau wrote:
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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 <tudor.girba(a)gmail.com>
> 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
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> Simon
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow."
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> <LAN sample
model-3.famix2.mse>_______________________________________________
Moose-dev
mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:06 p.m.
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 <johan.brichau(a)uclouvain.be>
now with my attachment... (sorry)
On 16 Feb 2010, at 20:50, Johan Brichau wrote:
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Reasonable is what we are accustomed with."
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 <tudor.girba(a)gmail.com>
> 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
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> Simon
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow."
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> <LAN sample
model-3.famix2.mse>_______________________________________________
Moose-dev
mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:07 p.m.
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 <johan.brichau(a)uclouvain.be>
now with my attachment... (sorry)
On 16 Feb 2010, at 20:50, Johan Brichau wrote:
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
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:
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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 <tudor.girba(a)gmail.com>
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
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
<LAN sample model-3.famix2.mse>_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:22 p.m.
I guess it should:) I will have a look at that tomorow.
2010/2/16 Johan Brichau <johan.brichau(a)uclouvain.be>
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:
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
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 <johan.brichau(a)uclouvain.be>
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 <tudor.girba(a)gmail.com>
>> 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
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> Simon
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "Every thing has its own flow."
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> <LAN sample
model-3.famix2.mse>_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:25 p.m.
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 <johan.brichau(a)uclouvain.be>
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:
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
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 <johan.brichau(a)uclouvain.be>
now with my attachment... (sorry)
On 16 Feb 2010, at 20:50, Johan Brichau wrote:
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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:
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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 <tudor.girba(a)gmail.com>
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
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
<LAN sample model-3.famix2.mse>_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
17 Feb
17 Feb
7:45 a.m.
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 <johan.brichau(a)uclouvain.be>
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:
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
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 <johan.brichau(a)uclouvain.be>
now with my attachment... (sorry)
On 16 Feb 2010, at 20:50, Johan Brichau wrote:
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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 <tudor.girba(a)gmail.com>
> 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
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> Simon
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow."
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> <LAN sample model-3.famix2.mse>_______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:04 a.m.
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 <jannik.laval(a)gmail.com>
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:
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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 <johan.brichau(a)uclouvain.be>
> 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 <johan.brichau(a)uclouvain.be>
>> 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 <tudor.girba(a)gmail.com>
>>>> 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
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> Simon
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "Every thing has its own flow."
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> <LAN sample
model-3.famix2.mse>_______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> ----------------------------
> Johan Brichau
> johan.brichau(a)uclouvain.be
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:17 a.m.
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 <jannik.laval(a)gmail.com>
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:
--
Simon
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev I guess it should:) I will have a look at that
tomorow.
2010/2/16 Johan Brichau <johan.brichau(a)uclouvain.be>
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:
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
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 <johan.brichau(a)uclouvain.be>
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 <tudor.girba(a)gmail.com>
>> 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
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> Simon
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "Every thing has its own flow."
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> <LAN sample
model-3.famix2.mse>_______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> ----------------------------
> Johan Brichau
> johan.brichau(a)uclouvain.be
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
1:40 p.m.
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 <Simon.Denier(a)inria.fr>
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 <jannik.laval(a)gmail.com>
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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 <johan.brichau(a)uclouvain.be>
> 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 <johan.brichau(a)uclouvain.be>
>> 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 <tudor.girba(a)gmail.com>
>>>> 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
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> Simon
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "Every thing has its own flow."
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> <LAN sample
model-3.famix2.mse>_______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> ----------------------------
>> Johan Brichau
>> johan.brichau(a)uclouvain.be
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> ----------------------------
> Johan Brichau
> johan.brichau(a)uclouvain.be
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4:03 p.m.
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 <Simon.Denier(a)inria.fr>
On 17 févr. 2010, at 11:04, Cyrille Delaunay wrote:
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
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 <jannik.laval(a)gmail.com>
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:
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev I guess it should:) I will have a look at that
tomorow.
2010/2/16 Johan Brichau <johan.brichau(a)uclouvain.be>
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 <johan.brichau(a)uclouvain.be>
> 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 <tudor.girba(a)gmail.com>
>>> 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
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> Simon
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Every thing has its own flow."
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> <LAN sample
model-3.famix2.mse>_______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> ----------------------------
>> Johan Brichau
>> johan.brichau(a)uclouvain.be
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> ----------------------------
> Johan Brichau
> johan.brichau(a)uclouvain.be
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
8:41 p.m.
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:
--
www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
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 <Simon.Denier(a)inria.fr>
On 17 févr. 2010, at 11:04, Cyrille Delaunay wrote:
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
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.
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 <jannik.laval(a)gmail.com>
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:
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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 <johan.brichau(a)uclouvain.be>
> 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 <johan.brichau(a)uclouvain.be>
>> 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 <tudor.girba(a)gmail.com>
>>>> 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
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> Simon
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "Every thing has its own flow."
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> <LAN sample
>>>> model
>>>> -3.famix2.mse>_______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> ----------------------------
>>> Johan Brichau
>>> johan.brichau(a)uclouvain.be
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> ----------------------------
>> Johan Brichau
>> johan.brichau(a)uclouvain.be
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> ----------------------------
> Johan Brichau
> johan.brichau(a)uclouvain.be
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
18 Feb
18 Feb
8:12 a.m.
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:
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
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:
--
www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
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 <Simon.Denier(a)inria.fr>
On 17 févr. 2010, at 11:04, Cyrille Delaunay wrote:
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
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.
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 <jannik.laval(a)gmail.com>
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 <johan.brichau(a)uclouvain.be>
>> 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 <johan.brichau(a)uclouvain.be>
>>> 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 <tudor.girba(a)gmail.com>
>>>>> 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
>>>>> Moose-dev(a)iam.unibe.ch
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>> --
>>>>> Simon
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> Moose-dev(a)iam.unibe.ch
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>> --
>>>>> www.tudorgirba.com
>>>>>
>>>>> "Every thing has its own flow."
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> Moose-dev(a)iam.unibe.ch
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>> <LAN sample
model-3.famix2.mse>_______________________________________________
>>>>> Moose-dev mailing list
>>>>> Moose-dev(a)iam.unibe.ch
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> ----------------------------
>>>> Johan Brichau
>>>> johan.brichau(a)uclouvain.be
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> ----------------------------
>>> Johan Brichau
>>> johan.brichau(a)uclouvain.be
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> ----------------------------
>> Johan Brichau
>> johan.brichau(a)uclouvain.be
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> ----------------------------
> Johan Brichau
> johan.brichau(a)uclouvain.be
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
9:05 a.m.
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:
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:
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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:
--
www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
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 <Simon.Denier(a)inria.fr>
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 <jannik.laval(a)gmail.com>
> 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 <johan.brichau(a)uclouvain.be>
>>> 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 <johan.brichau(a)uclouvain.be>
>>>> 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 <tudor.girba(a)gmail.com>
>>>>>> 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
>>>>>> Moose-dev(a)iam.unibe.ch
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>
>>>>>> --
>>>>>> Simon
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> Moose-dev(a)iam.unibe.ch
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>
>>>>>> --
>>>>>> www.tudorgirba.com
>>>>>>
>>>>>> "Every thing has its own flow."
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> Moose-dev(a)iam.unibe.ch
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>
>>>>>> <LAN sample
model-3.famix2.mse>_______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> Moose-dev(a)iam.unibe.ch
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>> ----------------------------
>>>>> Johan Brichau
>>>>> johan.brichau(a)uclouvain.be
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> Moose-dev(a)iam.unibe.ch
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> ----------------------------
>>>> Johan Brichau
>>>> johan.brichau(a)uclouvain.be
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> ----------------------------
>>> Johan Brichau
>>> johan.brichau(a)uclouvain.be
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> ----------------------------
>> Johan Brichau
>> johan.brichau(a)uclouvain.be
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
9:14 a.m.
New subject: Fwd: 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:
> 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?
>
10:06 a.m.
New subject: Fwd: Re: Famix2MSE importer Available in PharoMoose
I was converting the filestream into a readWriteStream so that the character
$( I add to it does not affect the file itself. If you let the fileStream
itself, I think your file will be modified and then you will not be able to
re-import it at all.
2010/2/18 Laval Jannik <jannik.laval(a)inria.fr>
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:
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?
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
12:06 p.m.
New subject: Fwd: Re: Famix2MSE importer Available in PharoMoose
Hi Cyrille,
Why exactly do you need to add a $(?
Cheers,
Doru
On 18 Feb 2010, at 10:06, Cyrille Delaunay wrote:
I was converting the filestream into a readWriteStream
so that the
character $( I add to it does not affect the file itself. If you let
the fileStream itself, I think your file will be modified and then
you will not be able to re-import it at all.
2010/2/18 Laval Jannik <jannik.laval(a)inria.fr>
--
www.tudorgirba.com
"When people care, great things can happen."
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:
> 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?
>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
1:11 p.m.
New subject: Fwd: Re: Famix2MSE importer Available in PharoMoose
Because a Famix3 mse file (in other words, the kind of file that the mse
parser accept) begins with:
'(
( entity ... '
To obtain this syntax from a famix2 mse file, I skip all that is present
before, and just add the first '(' so that the parser deals with this stream
like with any other famix3mse stream.
2010/2/18 Tudor Girba <tudor.girba(a)gmail.com>
Hi Cyrille,
Why exactly do you need to add a $(?
Cheers,
Doru
On 18 Feb 2010, at 10:06, Cyrille Delaunay wrote:
I was converting the filestream into a readWriteStream so that the
character $( I add to it does not affect the file
itself. If you let the
fileStream itself, I think your file will be modified and then you will not
be able to re-import it at all.
2010/2/18 Laval Jannik <jannik.laval(a)inria.fr>
--
www.tudorgirba.com
"When people care, great things can happen."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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:
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?
>
>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
1:49 p.m.
New subject: Fwd: Re: Famix2MSE importer Available in PharoMoose
Hi Cyrille,
The FAMIX2 preamble is
(Moose.Model
(entity
(...)
)
)
So, why is it not easier to just ignore the entity string? This would
imply no modification of the file.
Cheers,
Doru
On 18 Feb 2010, at 13:11, Cyrille Delaunay wrote:
Because a Famix3 mse file (in other words, the kind of
file that the
mse parser accept) begins with:
'(
( entity ... '
To obtain this syntax from a famix2 mse file, I skip all that is
present before, and just add the first '(' so that the parser deals
with this stream like with any other famix3mse stream.
2010/2/18 Tudor Girba <tudor.girba(a)gmail.com>
Hi Cyrille,
Why exactly do you need to add a $(?
Cheers,
Doru
On 18 Feb 2010, at 10:06, Cyrille Delaunay wrote:
I was converting the filestream into a readWriteStream so that the
character $( I add to it does not affect the file itself. If you let
the fileStream itself, I think your file will be modified and then
you will not be able to re-import it at all.
2010/2/18 Laval Jannik <jannik.laval(a)inria.fr>
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:
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?
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"When people care, great things can happen."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Some battles are better lost than fought."
2:05 p.m.
New subject: Fwd: Re: Famix2MSE importer Available in PharoMoose
Beacause 'ignore the entity string' means 'modify the Parser so that it
ignore the entity string'.
So, I found easier to not touch the parser but rather to give it a stream
ready to be parsed. Then, I choose to modify a stream with the file contents
rather than the file itself.
But this solution was maybe more 'faster' than 'easier'. So I don't
know if
it's the best solution. And now, we already have subclassed the classic
parser to make specific things, so it would not be very difficult to
override the method parsing the begening of the document.
2010/2/18 Tudor Girba <tudor.girba(a)gmail.com>
Hi Cyrille,
The FAMIX2 preamble is
(Moose.Model
(entity
(...)
)
)
So, why is it not easier to just ignore the entity string? This would imply
no modification of the file.
Cheers,
Doru
On 18 Feb 2010, at 13:11, Cyrille Delaunay wrote:
Because a Famix3 mse file (in other words, the kind of file that the mse
parser accept) begins with:
'(
( entity ... '
To obtain this syntax from a famix2 mse file, I skip all that is present
before, and just add the first '(' so that the parser deals with this stream
like with any other famix3mse stream.
2010/2/18 Tudor Girba <tudor.girba(a)gmail.com>
Hi Cyrille,
Why exactly do you need to add a $(?
Cheers,
Doru
On 18 Feb 2010, at 10:06, Cyrille Delaunay wrote:
I was converting the filestream into a readWriteStream so that the
character $( I add to it does not affect the file itself. If you let the
fileStream itself, I think your file will be modified and then you will not
be able to re-import it at all.
2010/2/18 Laval Jannik <jannik.laval(a)inria.fr>
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:
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?
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"When people care, great things can happen."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Some battles are better lost than fought."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5432
days inactive
5434
days old
25 comments
6 participants
participants (6)
-
Cyrille Delaunay -
Johan Brichau -
Laval Jannik -
Laval Jannik -
Simon Denier -
Tudor Girba