11 Nov
2011
11 Nov
'11
7:43 p.m.
Hi,
I had create several MSE files of different versions of a Java system
using VerveineJ. Then, I had tried to load them to the Moose Panel but
after load two of them I run out of memory in Moose (The Pharo error is "Space
is Low").
I had the same problem when loading several versions of Mondrian to Moose
Panel. However, we solved it by using the following script (we select only
those thing in which we are interested):
| mooseModel packages task |
#('2.10' '2.13' '2.100') do: [:version |
| project |
project := (ConfigurationOfMondrian project version: version).
[
project load.
"This is necessary by Moose to properly import"
Gofer new
url: '
http://www.squeaksource.com/CollectionExtensions'#39;;
version: 'CollectionExtensions-TudorGirba.29';
load.
packages := (project packages collect: #name) select: [:p |
p beginsWith: 'Mondrian'].
mooseModel := MooseModel new.
task := MooseSqueakClassCategoryImporterTask new.
task importerClass: SmalltalkImporter.
task importingContext mergeClassAndMetaclass.
task model: mooseModel.
task runCandidateOperator.
task addFromPackagesNamed: packages.
task runWithProgress.
mooseModel name: 'Mondrian ', version.
mooseModel allMethods do: #numberOfLinesOfCode.
mooseModel install.
] on: Error do: [ :ex | self halt. Transcript show: 'cannot load
version ', version, ' ', ex printString. ].
]
Is there any way to do the same with VerveineJ (that is, reduce the size of
the MSE files)? Or is there a way to expand the memory of Moose?
Thanks
--
Santiago Vidal
12 Nov
12 Nov
12:06 a.m.
I think that what Santiago is saying, is whether there is a way to customize the import
context when loading an mse model
Alexandre
Le 11 nov. 2011 à 10:43, Santiago Vidal <santiago.a.vidal(a)gmail.com> a écrit :
Hi,
I had create several MSE files of different versions of a Java system using VerveineJ.
Then, I had tried to load them to the Moose Panel but after load two of them I run out of
memory in Moose (The Pharo error is "Space is Low").
I had the same problem when loading several versions of Mondrian to Moose Panel. However,
we solved it by using the following script (we select only those thing in which we are
interested):
| mooseModel packages task |
#('2.10' '2.13' '2.100') do: [:version |
| project |
project := (ConfigurationOfMondrian project version: version).
[
project load.
"This is necessary by Moose to properly import"
Gofer new
url: 'http://www.squeaksource.com/CollectionExtensions';
version: 'CollectionExtensions-TudorGirba.29';
load.
packages := (project packages collect: #name) select: [:p | p beginsWith:
'Mondrian'].
mooseModel := MooseModel new.
task := MooseSqueakClassCategoryImporterTask new.
task importerClass: SmalltalkImporter.
task importingContext mergeClassAndMetaclass.
task model: mooseModel.
task runCandidateOperator.
task addFromPackagesNamed: packages.
task runWithProgress.
mooseModel name: 'Mondrian ', version.
mooseModel allMethods do: #numberOfLinesOfCode.
mooseModel install.
] on: Error do: [ :ex | self halt. Transcript show: 'cannot load version
', version, ' ', ex printString. ].
]
Is there any way to do the same with VerveineJ (that is, reduce the size of the MSE
files)? Or is there a way to expand the memory of Moose?
Thanks
--
Santiago Vidal
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
2:05 a.m.
Yep, thanks Alexandre
Enviado desde mi iPad
El 11/11/2011, a las 20:06, Alexandre Bergel <alexandre.bergel(a)me.com> escribió:
I think that what Santiago is saying, is whether there
is a way to customize the import context when loading an mse model
Alexandre
Le 11 nov. 2011 à 10:43, Santiago Vidal <santiago.a.vidal(a)gmail.com> a écrit :
Hi,
I had create several MSE files of different versions of a Java system using VerveineJ.
Then, I had tried to load them to the Moose Panel but after load two of them I run out of
memory in Moose (The Pharo error is "Space is Low").
I had the same problem when loading several versions of Mondrian to Moose Panel. However,
we solved it by using the following script (we select only those thing in which we are
interested):
| mooseModel packages task |
#('2.10' '2.13' '2.100') do: [:version |
| project |
project := (ConfigurationOfMondrian project version: version).
[
project load.
"This is necessary by Moose to properly import"
Gofer new
url: 'http://www.squeaksource.com/CollectionExtensions';
version: 'CollectionExtensions-TudorGirba.29';
load.
packages := (project packages collect: #name) select: [:p | p beginsWith:
'Mondrian'].
mooseModel := MooseModel new.
task := MooseSqueakClassCategoryImporterTask new.
task importerClass: SmalltalkImporter.
task importingContext mergeClassAndMetaclass.
task model: mooseModel.
task runCandidateOperator.
task addFromPackagesNamed: packages.
task runWithProgress.
mooseModel name: 'Mondrian ', version.
mooseModel allMethods do: #numberOfLinesOfCode.
mooseModel install.
] on: Error do: [ :ex | self halt. Transcript show: 'cannot load version
', version, ' ', ex printString. ].
]
Is there any way to do the same with VerveineJ (that is, reduce the size of the MSE
files)? Or is there a way to expand the memory of Moose?
Thanks
--
Santiago Vidal
_______________________________________________
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 
13 Nov
13 Nov
10:53 a.m.
Hi, as for the MSE importer I cannot help you. as for verveinej, there is one option you
can use: it will generate a smaller mse which may be what you need. However keep n mind
that this mean the MSE will not have all information. So if you later need more details,
they will not be available without a new parsing. Whereas tweaking the mse importer means
you have all the information in the mse and don't need to reparse if you want more
details, you only need to reload ... So, this said, and without further ado ... you can
use "-summary" which will generate a MSE at the class level, that is to say it
does not save members within classes (methods and attributes). It does not generate access
(because there are not attributes) not any invocations (because there are no methods)
instead, these are uplifted as dependencies between classes. Another possible (not
currently implemented) thing to do would be to add a "-noanchor" parameter that
would export all informations but not generate any source anchor. There are typically a
good number of these, so it should save a good deal of space. However, this could also
mean moose cannot compute LOC any more ... nicolas ----- Mail original -----
De: "Santiago Vidal"
<santiago.a.vidal(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Cc: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Samedi 12 Novembre 2011 02:05:01
Objet: [Moose-dev] Re: Help with VerveineJ
Yep, thanks Alexandre
Enviado desde mi iPad
El 11/11/2011, a las 20:06, Alexandre Bergel < alexandre.bergel(a)me.com
escribió:
I think that what Santiago is saying, is whether there is a way to
customize the import context when loading an mse model
Alexandre
Le 11 nov. 2011 à 10:43, Santiago Vidal < santiago.a.vidal(a)gmail.com
a écrit :
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi,
I had create several MSE files of different versions of a Java
system
using VerveineJ. Then, I had tried to load them to the Moose Panel
but
after load two of them I run out of memory in Moose (The Pharo
error
is " Space is Low" ).
I had the same problem when loading several versions of Mondrian
to
Moose Panel. However, we solved it by using the following script
(we
select only those thing in which we are interested):
| mooseModel packages task |
#('2.10' '2.13' '2.100') do: [:version |
| project |
project := (ConfigurationOfMondrian project version: version).
[
project load.
"This is necessary by Moose to properly import"
Gofer new
url: ' http://www.squeaksource.com/CollectionExtensions ';
version: 'CollectionExtensions-TudorGirba.29';
load.
packages := (project packages collect: #name) select: [:p | p
beginsWith: 'Mondrian'].
mooseModel := MooseModel new.
task := MooseSqueakClassCategoryImporterTask new.
task importerClass: SmalltalkImporter.
task importingContext mergeClassAndMetaclass.
task model: mooseModel.
task runCandidateOperator.
task addFromPackagesNamed: packages.
task runWithProgress.
mooseModel name: 'Mondrian ', version.
mooseModel allMethods do: #numberOfLinesOfCode.
mooseModel install.
] on: Error do: [ :ex | self halt. Transcript show: 'cannot load
version ', version, ' ', ex printString. ].
]
Is there any way to do the same with VerveineJ (that is, reduce
the
size of the MSE files)? Or is there a way to expand the memory of
Moose?
Thanks
--
Santiago Vidal
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
4:12 p.m.
If I remember Andre did a custom mse loader that can filter entities to be loaded.
Now I will wait for his answer
In general this is a good idea to extract at maximum level and to filter while loading.
Stef
On Nov 11, 2011, at 7:43 PM, Santiago Vidal wrote:
Hi,
I had create several MSE files of different versions of a Java system using VerveineJ.
Then, I had tried to load them to the Moose Panel but after load two of them I run out of
memory in Moose (The Pharo error is "Space is Low").
I had the same problem when loading several versions of Mondrian to Moose Panel. However,
we solved it by using the following script (we select only those thing in which we are
interested):
| mooseModel packages task |
#('2.10' '2.13' '2.100') do: [:version |
| project |
project := (ConfigurationOfMondrian project version: version).
[
project load.
"This is necessary by Moose to properly import"
Gofer new
url: 'http://www.squeaksource.com/CollectionExtensions';
version: 'CollectionExtensions-TudorGirba.29';
load.
packages := (project packages collect: #name) select: [:p | p beginsWith:
'Mondrian'].
mooseModel := MooseModel new.
task := MooseSqueakClassCategoryImporterTask new.
task importerClass: SmalltalkImporter.
task importingContext mergeClassAndMetaclass.
task model: mooseModel.
task runCandidateOperator.
task addFromPackagesNamed: packages.
task runWithProgress.
mooseModel name: 'Mondrian ', version.
mooseModel allMethods do: #numberOfLinesOfCode.
mooseModel install.
] on: Error do: [ :ex | self halt. Transcript show: 'cannot load version
', version, ' ', ex printString. ].
]
Is there any way to do the same with VerveineJ (that is, reduce the size of the MSE
files)? Or is there a way to expand the memory of Moose?
Thanks
--
Santiago Vidal
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
9:22 p.m.
+1.
We now have the basic mechanism for loading partial models. But, I will let Andre answer
more details.
Andre, you have the floor :)
Cheers,
Doru
On 13 Nov 2011, at 16:12, Stéphane Ducasse wrote:
If I remember Andre did a custom mse loader that can
filter entities to be loaded.
Now I will wait for his answer
In general this is a good idea to extract at maximum level and to filter while loading.
Stef
On Nov 11, 2011, at 7:43 PM, Santiago Vidal wrote:
--
www.tudorgirba.com
"One cannot do more than one can do."
Hi,
I had create several MSE files of different versions of a Java system using VerveineJ.
Then, I had tried to load them to the Moose Panel but after load two of them I run out of
memory in Moose (The Pharo error is "Space is Low").
I had the same problem when loading several versions of Mondrian to Moose Panel. However,
we solved it by using the following script (we select only those thing in which we are
interested):
| mooseModel packages task |
#('2.10' '2.13' '2.100') do: [:version |
| project |
project := (ConfigurationOfMondrian project version: version).
[
project load.
"This is necessary by Moose to properly import"
Gofer new
url: 'http://www.squeaksource.com/CollectionExtensions';
version: 'CollectionExtensions-TudorGirba.29';
load.
packages := (project packages collect: #name) select: [:p | p beginsWith:
'Mondrian'].
mooseModel := MooseModel new.
task := MooseSqueakClassCategoryImporterTask new.
task importerClass: SmalltalkImporter.
task importingContext mergeClassAndMetaclass.
task model: mooseModel.
task runCandidateOperator.
task addFromPackagesNamed: packages.
task runWithProgress.
mooseModel name: 'Mondrian ', version.
mooseModel allMethods do: #numberOfLinesOfCode.
mooseModel install.
] on: Error do: [ :ex | self halt. Transcript show: 'cannot load version ',
version, ' ', ex printString. ].
]
Is there any way to do the same with VerveineJ (that is, reduce the size of the MSE
files)? Or is there a way to expand the memory of Moose?
Thanks
--
Santiago Vidal
_______________________________________________
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:39 p.m.
FYI
andre is on holiday till Wednesday
nicolas
----- Mail original -----
De: "Tudor Girba"
<tudor(a)tudorgirba.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Dimanche 13 Novembre 2011 21:22:06
Objet: [Moose-dev] Re: Help with VerveineJ
+1.
We now have the basic mechanism for loading partial models. But, I
will let Andre answer more details.
Andre, you have the floor :)
Cheers,
Doru
On 13 Nov 2011, at 16:12, Stéphane Ducasse wrote:
If I remember Andre did a custom mse loader that
can filter entities
to be loaded.
Now I will wait for his answer
In general this is a good idea to extract at maximum level and to
filter while loading.
Stef
On Nov 11, 2011, at 7:43 PM, Santiago Vidal wrote:
--
www.tudorgirba.com
"One cannot do more than one can do."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi,
I had create several MSE files of different versions of a Java
system using VerveineJ. Then, I had tried to load them to the Moose
Panel but after load two of them I run out of memory in Moose (The
Pharo error is "Space is Low").
I had the same problem when loading several versions of Mondrian to
Moose Panel. However, we solved it by using the following script
(we select only those thing in which we are interested):
| mooseModel packages task |
#('2.10' '2.13' '2.100') do: [:version |
| project |
project := (ConfigurationOfMondrian project version:
version).
[
project load.
"This is necessary by Moose to properly import"
Gofer new
url:
'http://www.squeaksource.com/CollectionExtensions';
version:
'CollectionExtensions-TudorGirba.29';
load.
packages := (project packages collect: #name) select:
[:p | p beginsWith: 'Mondrian'].
mooseModel := MooseModel new.
task := MooseSqueakClassCategoryImporterTask new.
task importerClass: SmalltalkImporter.
task importingContext mergeClassAndMetaclass.
task model: mooseModel.
task runCandidateOperator.
task addFromPackagesNamed: packages.
task runWithProgress.
mooseModel name: 'Mondrian ', version.
mooseModel allMethods do: #numberOfLinesOfCode.
mooseModel install.
] on: Error do: [ :ex | self halt. Transcript show: 'cannot
load version ', version, ' ', ex printString. ].
]
Is there any way to do the same with VerveineJ (that is, reduce the
size of the MSE files)? Or is there a way to expand the memory of
Moose?
Thanks
--
Santiago Vidal
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:38 p.m.
Thanks for the answers! I will wait for Andre's answer
Cheers
Santiago
2011/11/13 Nicolas Anquetil <nicolas.anquetil(a)inria.fr>
FYI
andre is on holiday till Wednesday
nicolas
----- Mail original -----
--
www.tudorgirba.com
"One cannot do more than one can do."
_______________________________________________
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
--
Santiago Vidal
De: "Tudor Girba"
<tudor(a)tudorgirba.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Dimanche 13 Novembre 2011 21:22:06
Objet: [Moose-dev] Re: Help with VerveineJ
+1.
We now have the basic mechanism for loading partial models. But, I
will let Andre answer more details.
Andre, you have the floor :)
Cheers,
Doru
On 13 Nov 2011, at 16:12, Stéphane Ducasse wrote:
> If I remember Andre did a custom mse loader that can filter entities
> to be loaded.
> Now I will wait for his answer
>
> In general this is a good idea to extract at maximum level and to
> filter while loading.
>
> Stef
>
> On Nov 11, 2011, at 7:43 PM, Santiago Vidal wrote:
>
>> Hi,
>> I had create several MSE files of different versions of a Java
>> system using VerveineJ. Then, I had tried to load them to the Moose
>> Panel but after load two of them I run out of memory in Moose (The
>> Pharo error is "Space is Low").
>> I had the same problem when loading several versions of Mondrian to
>> Moose Panel. However, we solved it by using the following script
>> (we select only those thing in which we are interested):
>>
>> | mooseModel packages task |
>>
>> #('2.10' '2.13' '2.100') do: [:version |
>> | project |
>> project := (ConfigurationOfMondrian project version:
>> version).
>>
>> [
>> project load.
>>
>> "This is necessary by Moose to properly import"
>> Gofer new
>> url:
>> '
http://www.squeaksource.com/CollectionExtensions'#39;;
version:
'CollectionExtensions-TudorGirba.29';
load.
packages := (project packages collect: #name) select:
[:p | p beginsWith: 'Mondrian'].
mooseModel := MooseModel new.
task := MooseSqueakClassCategoryImporterTask new.
task importerClass: SmalltalkImporter.
task importingContext mergeClassAndMetaclass.
task model: mooseModel.
task runCandidateOperator.
task addFromPackagesNamed: packages.
task runWithProgress.
mooseModel name: 'Mondrian ', version.
mooseModel allMethods do: #numberOfLinesOfCode.
mooseModel install.
] on: Error do: [ :ex | self halt. Transcript show: 'cannot
load version ', version, ' ', ex printString. ].
]
Is there any way to do the same with VerveineJ (that is, reduce the
size of the MSE files)? Or is there a way to expand the memory of
Moose?
Thanks
--
Santiago Vidal
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:51 p.m.
Thanks :).
Andre, when you come back, we should pick up where we left and look into the integration
of the Fame filter in Moose.
Cheers,
Doru
On 13 Nov 2011, at 21:39, Nicolas Anquetil wrote:
FYI
andre is on holiday till Wednesday
nicolas
----- Mail original -----
--
www.tudorgirba.com
"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."
De: "Tudor Girba"
<tudor(a)tudorgirba.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Dimanche 13 Novembre 2011 21:22:06
Objet: [Moose-dev] Re: Help with VerveineJ
+1.
We now have the basic mechanism for loading partial models. But, I
will let Andre answer more details.
Andre, you have the floor :)
Cheers,
Doru
On 13 Nov 2011, at 16:12, Stéphane Ducasse wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev If I remember Andre did a custom mse loader that
can filter entities
to be loaded.
Now I will wait for his answer
In general this is a good idea to extract at maximum level and to
filter while loading.
Stef
On Nov 11, 2011, at 7:43 PM, Santiago Vidal wrote:
--
www.tudorgirba.com
"One cannot do more than one can do."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi,
I had create several MSE files of different versions of a Java
system using VerveineJ. Then, I had tried to load them to the Moose
Panel but after load two of them I run out of memory in Moose (The
Pharo error is "Space is Low").
I had the same problem when loading several versions of Mondrian to
Moose Panel. However, we solved it by using the following script
(we select only those thing in which we are interested):
| mooseModel packages task |
#('2.10' '2.13' '2.100') do: [:version |
| project |
project := (ConfigurationOfMondrian project version:
version).
[
project load.
"This is necessary by Moose to properly import"
Gofer new
url:
'http://www.squeaksource.com/CollectionExtensions';
version:
'CollectionExtensions-TudorGirba.29';
load.
packages := (project packages collect: #name) select:
[:p | p beginsWith: 'Mondrian'].
mooseModel := MooseModel new.
task := MooseSqueakClassCategoryImporterTask new.
task importerClass: SmalltalkImporter.
task importingContext mergeClassAndMetaclass.
task model: mooseModel.
task runCandidateOperator.
task addFromPackagesNamed: packages.
task runWithProgress.
mooseModel name: 'Mondrian ', version.
mooseModel allMethods do: #numberOfLinesOfCode.
mooseModel install.
] on: Error do: [ :ex | self halt. Transcript show: 'cannot
load version ', version, ' ', ex printString. ].
]
Is there any way to do the same with VerveineJ (that is, reduce the
size of the MSE files)? Or is there a way to expand the memory of
Moose?
Thanks
--
Santiago Vidal
_______________________________________________
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:13 p.m.
I want to know in particular how the consistency of the resulting model is handled.
Thanks :).
Andre, when you come back, we should pick up where we left and look into the integration
of the Fame filter in Moose.
Cheers,
Doru
On 13 Nov 2011, at 21:39, Nicolas Anquetil wrote:
FYI
andre is on holiday till Wednesday
nicolas
----- Mail original -----
--
www.tudorgirba.com
"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev De: "Tudor Girba"
<tudor(a)tudorgirba.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Dimanche 13 Novembre 2011 21:22:06
Objet: [Moose-dev] Re: Help with VerveineJ
+1.
We now have the basic mechanism for loading partial models. But, I
will let Andre answer more details.
Andre, you have the floor :)
Cheers,
Doru
On 13 Nov 2011, at 16:12, Stéphane Ducasse wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev If I remember Andre did a custom mse loader that
can filter entities
to be loaded.
Now I will wait for his answer
In general this is a good idea to extract at maximum level and to
filter while loading.
Stef
On Nov 11, 2011, at 7:43 PM, Santiago Vidal wrote:
> Hi,
> I had create several MSE files of different versions of a Java
> system using VerveineJ. Then, I had tried to load them to the Moose
> Panel but after load two of them I run out of memory in Moose (The
> Pharo error is "Space is Low").
> I had the same problem when loading several versions of Mondrian to
> Moose Panel. However, we solved it by using the following script
> (we select only those thing in which we are interested):
>
> | mooseModel packages task |
>
> #('2.10' '2.13' '2.100') do: [:version |
> | project |
> project := (ConfigurationOfMondrian project version:
> version).
>
> [
> project load.
>
> "This is necessary by Moose to properly import"
> Gofer new
> url:
> 'http://www.squeaksource.com/CollectionExtensions';
> version:
> 'CollectionExtensions-TudorGirba.29';
> load.
>
> packages := (project packages collect: #name) select:
> [:p | p beginsWith: 'Mondrian'].
> mooseModel := MooseModel new.
> task := MooseSqueakClassCategoryImporterTask new.
> task importerClass: SmalltalkImporter.
> task importingContext mergeClassAndMetaclass.
> task model: mooseModel.
> task runCandidateOperator.
> task addFromPackagesNamed: packages.
> task runWithProgress.
>
> mooseModel name: 'Mondrian ', version.
> mooseModel allMethods do: #numberOfLinesOfCode.
> mooseModel install.
> ] on: Error do: [ :ex | self halt. Transcript show: 'cannot
> load version ', version, ' ', ex printString. ].
> ]
>
> Is there any way to do the same with VerveineJ (that is, reduce the
> size of the MSE files)? Or is there a way to expand the memory of
> Moose?
> Thanks
>
> --
> Santiago Vidal
> _______________________________________________
> 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
"One cannot do more than one can do."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
14 Nov
14 Nov
7:59 a.m.
The consistency is achieved by having a filtering mechanism that works based on the
information from the meta-model. When you filter by saying that you only want classes, the
filter will produce a consistent but smaller meta-model that will contain what is needed
for the class to be appropriately described.
I think there is still one issue left in the algorithm, but first we should see how it
performs on larger case studies.
In any case, one side-effect is that the information from the ImportingContext should not
be needed anymore because we could finally reuse the one from the original
meta-descriptions.
Cheers,
Doru
On 13 Nov 2011, at 23:13, Stéphane Ducasse wrote:
I want to know in particular how the consistency of
the resulting model is handled.
--
www.tudorgirba.com
"Presenting is storytelling."
Thanks :).
Andre, when you come back, we should pick up where we left and look into the integration
of the Fame filter in Moose.
Cheers,
Doru
On 13 Nov 2011, at 21:39, Nicolas Anquetil wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev FYI
andre is on holiday till Wednesday
nicolas
----- Mail original -----
--
www.tudorgirba.com
"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev De: "Tudor Girba"
<tudor(a)tudorgirba.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Dimanche 13 Novembre 2011 21:22:06
Objet: [Moose-dev] Re: Help with VerveineJ
+1.
We now have the basic mechanism for loading partial models. But, I
will let Andre answer more details.
Andre, you have the floor :)
Cheers,
Doru
On 13 Nov 2011, at 16:12, Stéphane Ducasse wrote:
> If I remember Andre did a custom mse loader that can filter entities
> to be loaded.
> Now I will wait for his answer
>
> In general this is a good idea to extract at maximum level and to
> filter while loading.
>
> Stef
>
> On Nov 11, 2011, at 7:43 PM, Santiago Vidal wrote:
>
>> Hi,
>> I had create several MSE files of different versions of a Java
>> system using VerveineJ. Then, I had tried to load them to the Moose
>> Panel but after load two of them I run out of memory in Moose (The
>> Pharo error is "Space is Low").
>> I had the same problem when loading several versions of Mondrian to
>> Moose Panel. However, we solved it by using the following script
>> (we select only those thing in which we are interested):
>>
>> | mooseModel packages task |
>>
>> #('2.10' '2.13' '2.100') do: [:version |
>> | project |
>> project := (ConfigurationOfMondrian project version:
>> version).
>>
>> [
>> project load.
>>
>> "This is necessary by Moose to properly import"
>> Gofer new
>> url:
>> 'http://www.squeaksource.com/CollectionExtensions';
>> version:
>> 'CollectionExtensions-TudorGirba.29';
>> load.
>>
>> packages := (project packages collect: #name) select:
>> [:p | p beginsWith: 'Mondrian'].
>> mooseModel := MooseModel new.
>> task := MooseSqueakClassCategoryImporterTask new.
>> task importerClass: SmalltalkImporter.
>> task importingContext mergeClassAndMetaclass.
>> task model: mooseModel.
>> task runCandidateOperator.
>> task addFromPackagesNamed: packages.
>> task runWithProgress.
>>
>> mooseModel name: 'Mondrian ', version.
>> mooseModel allMethods do: #numberOfLinesOfCode.
>> mooseModel install.
>> ] on: Error do: [ :ex | self halt. Transcript show: 'cannot
>> load version ', version, ' ', ex printString. ].
>> ]
>>
>> Is there any way to do the same with VerveineJ (that is, reduce the
>> size of the MSE files)? Or is there a way to expand the memory of
>> Moose?
>> Thanks
>>
>> --
>> Santiago Vidal
>> _______________________________________________
>> 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
"One cannot do more than one can do."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:51 a.m.
On Nov 14, 2011, at 7:59 AM, Tudor Girba wrote:
The consistency is achieved by having a filtering
mechanism that works based on the information from the meta-model. When you filter by
saying that you only want classes, the filter will produce a consistent but smaller
meta-model that will contain what is needed for the class to be appropriately described.
I think there is still one issue left in the algorithm, but first we should see how it
performs on larger case studies.
In any case, one side-effect is that the information from the ImportingContext should not
be needed anymore because we could finally reuse the one from the original
meta-descriptions.
Ok but then it means that you should have the dependencies expressed clearly at the meta
model.
and remove importingContext.
Because having two mechanisms is not a good idea on the long term.
Stef
Cheers,
Doru
On 13 Nov 2011, at 23:13, Stéphane Ducasse wrote:
I want to know in particular how the consistency
of the resulting model is handled.
--
www.tudorgirba.com
"Presenting is storytelling."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Thanks :).
Andre, when you come back, we should pick up where we left and look into the integration
of the Fame filter in Moose.
Cheers,
Doru
On 13 Nov 2011, at 21:39, Nicolas Anquetil wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev FYI
andre is on holiday till Wednesday
nicolas
----- Mail original -----
> De: "Tudor Girba" <tudor(a)tudorgirba.com>
> À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
> Envoyé: Dimanche 13 Novembre 2011 21:22:06
> Objet: [Moose-dev] Re: Help with VerveineJ
> +1.
>
> We now have the basic mechanism for loading partial models. But, I
> will let Andre answer more details.
>
> Andre, you have the floor :)
>
> Cheers,
> Doru
>
>
> On 13 Nov 2011, at 16:12, Stéphane Ducasse wrote:
>
>> If I remember Andre did a custom mse loader that can filter entities
>> to be loaded.
>> Now I will wait for his answer
>>
>> In general this is a good idea to extract at maximum level and to
>> filter while loading.
>>
>> Stef
>>
>> On Nov 11, 2011, at 7:43 PM, Santiago Vidal wrote:
>>
>>> Hi,
>>> I had create several MSE files of different versions of a Java
>>> system using VerveineJ. Then, I had tried to load them to the Moose
>>> Panel but after load two of them I run out of memory in Moose (The
>>> Pharo error is "Space is Low").
>>> I had the same problem when loading several versions of Mondrian to
>>> Moose Panel. However, we solved it by using the following script
>>> (we select only those thing in which we are interested):
>>>
>>> | mooseModel packages task |
>>>
>>> #('2.10' '2.13' '2.100') do: [:version |
>>> | project |
>>> project := (ConfigurationOfMondrian project version:
>>> version).
>>>
>>> [
>>> project load.
>>>
>>> "This is necessary by Moose to properly import"
>>> Gofer new
>>> url:
>>>
'http://www.squeaksource.com/CollectionExtensions';
>>> version:
>>> 'CollectionExtensions-TudorGirba.29';
>>> load.
>>>
>>> packages := (project packages collect: #name) select:
>>> [:p | p beginsWith: 'Mondrian'].
>>> mooseModel := MooseModel new.
>>> task := MooseSqueakClassCategoryImporterTask new.
>>> task importerClass: SmalltalkImporter.
>>> task importingContext mergeClassAndMetaclass.
>>> task model: mooseModel.
>>> task runCandidateOperator.
>>> task addFromPackagesNamed: packages.
>>> task runWithProgress.
>>>
>>> mooseModel name: 'Mondrian ', version.
>>> mooseModel allMethods do: #numberOfLinesOfCode.
>>> mooseModel install.
>>> ] on: Error do: [ :ex | self halt. Transcript show: 'cannot
>>> load version ', version, ' ', ex printString. ].
>>> ]
>>>
>>> Is there any way to do the same with VerveineJ (that is, reduce the
>>> size of the MSE files)? Or is there a way to expand the memory of
>>> Moose?
>>> Thanks
>>>
>>> --
>>> Santiago Vidal
>>> _______________________________________________
>>> 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
>
> "One cannot do more than one can do."
>
>
>
>
> _______________________________________________
> 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
"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11 a.m.
Hi,
On Mon, Nov 14, 2011 at 10:51 AM, Stéphane Ducasse <
stephane.ducasse(a)inria.fr> wrote:
On Nov 14, 2011, at 7:59 AM, Tudor Girba wrote:
We have them in the form of property declared types. Furthermore, we also
take into account the derived information. So, if a property is derived, we
do not take it into account when computing the dependencies.
It works quite well. The only problem is that when the declared type is
generic we have to include in the dependencies all the subclasses. For
example, the type of inheritance superclass is Type, and this means that if
we want to load inheritances, we have to consider all entities that are
subclasses of Type (FAMIXClass, FAMIXTypeAlias ...).
This works well in almost all cases. The problem is with
annotationInstances which point to FAMIXEntity. So, currently, if you want
to load an annotation instance, you will end up loading the entire famix. I
guess we have to revisit the type of annotation instance to maybe be only a
named entity.
The consistency is achieved by having a filtering
mechanism that works
based on the information from the meta-model. When you filter
by saying
that you only want classes, the filter will produce a consistent but
smaller meta-model that will contain what is needed for the class to be
appropriately described.
I think there is still one issue left in the algorithm, but first we
should see
how it performs on larger case studies.
In any case, one side-effect is that the information from the
ImportingContext
should not be needed anymore because we could finally
reuse the one from the original meta-descriptions.
Ok but then it means that you should have the dependencies expressed
clearly at the meta model.
and remove importingContext.
Because having two mechanisms is not a good idea on
the long term.
Exactly :).
Doru
Stef
--
www.tudorgirba.com
"Presenting is storytelling."
_______________________________________________
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
"Every thing has its own flow"
Cheers,
Doru
On 13 Nov 2011, at 23:13, Stéphane Ducasse wrote:
> I want to know in particular how the consistency of the resulting model
is
handled.
>
>
>> Thanks :).
>>
>> Andre, when you come back, we should pick up where we left and look
into
the integration of the Fame filter in Moose.
>>
>> Cheers,
>> Doru
>>
>>
>> On 13 Nov 2011, at 21:39, Nicolas Anquetil wrote:
>>
>>> FYI
>>>
>>> andre is on holiday till Wednesday
>>>
>>> nicolas
>>>
>>> ----- Mail original -----
>>>> De: "Tudor Girba" <tudor(a)tudorgirba.com>
>>>> À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
>>>> Envoyé: Dimanche 13 Novembre 2011 21:22:06
>>>> Objet: [Moose-dev] Re: Help with VerveineJ
>>>> +1.
>>>>
>>>> We now have the basic mechanism for loading partial models. But, I
>>>> will let Andre answer more details.
>>>>
>>>> Andre, you have the floor :)
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>>
>>>> On 13 Nov 2011, at 16:12, Stéphane Ducasse wrote:
>>>>
>>>>> If I remember Andre did a custom mse loader that can filter entities
>>>>> to be loaded.
>>>>> Now I will wait for his answer
>>>>>
>>>>> In general this is a good idea to extract at maximum level and to
>>>>> filter while loading.
>>>>>
>>>>> Stef
>>>>>
>>>>> On Nov 11, 2011, at 7:43 PM, Santiago Vidal wrote:
>>>>>
>>>>>> Hi,
>>>>>> I had create several MSE files of different versions of a Java
>>>>>> system using VerveineJ. Then, I had tried to load them to the
Moose
>>>>>> Panel but after load two of them I run out of memory in Moose
(The
>>>>>> Pharo error is "Space is Low").
>>>>>> I had the same problem when loading several versions of Mondrian
to
>>>>>> Moose Panel. However, we solved it by using the following script
>>>>>> (we select only those thing in which we are interested):
>>>>>>
>>>>>> | mooseModel packages task |
>>>>>>
>>>>>> #('2.10' '2.13' '2.100') do: [:version |
>>>>>> | project |
>>>>>> project := (ConfigurationOfMondrian project version:
>>>>>> version).
>>>>>>
>>>>>> [
>>>>>> project load.
>>>>>>
>>>>>> "This is necessary by Moose to properly
import"
>>>>>> Gofer new
>>>>>> url:
>>>>>> '
http://www.squeaksource.com/CollectionExtensions'#39;;
>>>> version:
>>>> 'CollectionExtensions-TudorGirba.29';
>>>> load.
>>>>
>>>> packages := (project packages collect: #name) select:
>>>> [:p | p beginsWith: 'Mondrian'].
>>>> mooseModel := MooseModel new.
>>>> task := MooseSqueakClassCategoryImporterTask new.
>>>> task importerClass: SmalltalkImporter.
>>>> task importingContext mergeClassAndMetaclass.
>>>> task model: mooseModel.
>>>> task runCandidateOperator.
>>>> task addFromPackagesNamed: packages.
>>>> task runWithProgress.
>>>>
>>>> mooseModel name: 'Mondrian ', version.
>>>> mooseModel allMethods do: #numberOfLinesOfCode.
>>>> mooseModel install.
>>>> ] on: Error do: [ :ex | self halt. Transcript show: 'cannot
>>>> load version ', version, ' ', ex printString. ].
>>>> ]
>>>>
>>>> Is there any way to do the same with VerveineJ (that is, reduce the
>>>> size of the MSE files)? Or is there a way to expand the memory of
>>>> Moose?
>>>> Thanks
>>>>
>>>> --
>>>> Santiago Vidal
>>>> _______________________________________________
>>>> 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
>>
>> "One cannot do more than one can do."
>>
>>
>>
>>
>> _______________________________________________
>> 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
"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
16 Nov
16 Nov
3:44 p.m.
Hello Santiago,
You can find the custom loader Stef cited in: HoraExpTemp3 in SqueakSource
(load all the packages not related to Hismo). Then go to the Moose Panel
and click in "Import model from model from MSE file with context".
In fact I just fixed the wizard MooseImportFromMseWizard and used the
already implemented classes FMImporterFilter and FMParseClientFilter to
filter the model. The logic was already implemented.
regards,
So, the same idea we used to
On Mon, Nov 14, 2011 at 11:00 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
Hi,
On Mon, Nov 14, 2011 at 10:51 AM, Stéphane Ducasse <
stephane.ducasse(a)inria.fr> wrote:
--
Andre Hora
On Nov 14, 2011, at 7:59 AM, Tudor Girba wrote:
We have them in the form of property declared types. Furthermore, we also
take into account the derived information. So, if a property is derived, we
do not take it into account when computing the dependencies.
It works quite well. The only problem is that when the declared type is
generic we have to include in the dependencies all the subclasses. For
example, the type of inheritance superclass is Type, and this means that if
we want to load inheritances, we have to consider all entities that are
subclasses of Type (FAMIXClass, FAMIXTypeAlias ...).
This works well in almost all cases. The problem is with
annotationInstances which point to FAMIXEntity. So, currently, if you want
to load an annotation instance, you will end up loading the entire famix. I
guess we have to revisit the type of annotation instance to maybe be only a
named entity.
The consistency is achieved by having a filtering
mechanism that works
based on the information from the meta-model. When you filter
by saying
that you only want classes, the filter will produce a consistent but
smaller meta-model that will contain what is needed for the class to be
appropriately described.
I think there is still one issue left in the algorithm, but first we
should see
how it performs on larger case studies.
In any case, one side-effect is that the information from the
ImportingContext
should not be needed anymore because we could finally
reuse the one from the original meta-descriptions.
Ok but then it means that you should have the dependencies expressed
clearly at the meta model.
and remove importingContext.
Because having two mechanisms is not a good idea
on the long term.
Exactly :).
Doru
Stef
_______________________________________________
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
Cheers,
Doru
On 13 Nov 2011, at 23:13, Stéphane Ducasse wrote:
> I want to know in particular how the consistency of the resulting
model is
handled.
>
>
>> Thanks :).
>>
>> Andre, when you come back, we should pick up where we left and look
into
the integration of the Fame filter in Moose.
>>
>> Cheers,
>> Doru
>>
>>
>> On 13 Nov 2011, at 21:39, Nicolas Anquetil wrote:
>>
>>> FYI
>>>
>>> andre is on holiday till Wednesday
>>>
>>> nicolas
>>>
>>> ----- Mail original -----
>>>> De: "Tudor Girba" <tudor(a)tudorgirba.com>
>>>> À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
>>>> Envoyé: Dimanche 13 Novembre 2011 21:22:06
>>>> Objet: [Moose-dev] Re: Help with VerveineJ
>>>> +1.
>>>>
>>>> We now have the basic mechanism for loading partial models. But, I
>>>> will let Andre answer more details.
>>>>
>>>> Andre, you have the floor :)
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>>
>>>> On 13 Nov 2011, at 16:12, Stéphane Ducasse wrote:
>>>>
>>>>> If I remember Andre did a custom mse loader that can filter
entities
>>>>> to be loaded.
>>>>> Now I will wait for his answer
>>>>>
>>>>> In general this is a good idea to extract at maximum level and to
>>>>> filter while loading.
>>>>>
>>>>> Stef
>>>>>
>>>>> On Nov 11, 2011, at 7:43 PM, Santiago Vidal wrote:
>>>>>
>>>>>> Hi,
>>>>>> I had create several MSE files of different versions of a Java
>>>>>> system using VerveineJ. Then, I had tried to load them to the
Moose
>>>>>> Panel but after load two
of them I run out of memory in Moose (The
>>>>>> Pharo error is "Space is Low").
>>>>>> I had the same problem when loading several versions of Mondrian
to
>>>>>> Moose Panel. However, we
solved it by using the following script
>>>>>> (we select only those thing in which we are interested):
>>>>>>
>>>>>> | mooseModel packages task |
>>>>>>
>>>>>> #('2.10' '2.13' '2.100') do: [:version |
>>>>>> | project |
>>>>>> project := (ConfigurationOfMondrian project version:
>>>>>> version).
>>>>>>
>>>>>> [
>>>>>> project load.
>>>>>>
>>>>>> "This is necessary by Moose to properly
import"
>>>>>> Gofer new
>>>>>> url:
>>>>>> '
http://www.squeaksource.com/CollectionExtensions'#39;;
>>>>>>
version:
>>>>>> 'CollectionExtensions-TudorGirba.29';
>>>>>> load.
>>>>>>
>>>>>> packages := (project packages collect: #name) select:
>>>>>> [:p | p beginsWith: 'Mondrian'].
>>>>>> mooseModel := MooseModel new.
>>>>>> task := MooseSqueakClassCategoryImporterTask new.
>>>>>> task importerClass: SmalltalkImporter.
>>>>>> task importingContext mergeClassAndMetaclass.
>>>>>> task model: mooseModel.
>>>>>> task runCandidateOperator.
>>>>>> task addFromPackagesNamed: packages.
>>>>>> task runWithProgress.
>>>>>>
>>>>>> mooseModel name: 'Mondrian ', version.
>>>>>> mooseModel allMethods do: #numberOfLinesOfCode.
>>>>>> mooseModel install.
>>>>>> ] on: Error do: [ :ex | self halt. Transcript show:
'cannot
>>>>>> load version ', version, ' ', ex printString. ].
>>>>>> ]
>>>>>>
>>>>>> Is there any way to do the same with VerveineJ (that is, reduce
the
>>>>> size of the MSE files)? Or is there a way to expand the memory of
>>>>> Moose?
>>>>> Thanks
>>>>>
>>>>> --
>>>>> Santiago Vidal
>>>>> _______________________________________________
>>>>> 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
>>>
>>> "One cannot do more than one can do."
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
> "In a world where everything is moving ever faster,
> one might have better chances to win by moving slower."
>
>
>
>
> _______________________________________________
> 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
"Presenting is storytelling."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
3:49 p.m.
Hello,
As I said in the previous email we have a filtered loader working ok where
I basically reused some classes. The implementation is based on a
importContext to filter the imported model.
However, I am not sure if it is the best implementation because we are
using a separated filter (the context) but the filter should be the
meta-model (i.e., we should use FMMetaRepositoryFilter, the same we did
with the filtered exporter). Like that I guess we can even remove the
classes FMImporterFilter and FMParseClientFilter.
So, Doru, to use our implemented FMMetaRepositoryFilter to export filtered
models, you remember that we needed to adapt the classes
FMRepositoryVisitor, FMRepository and FMMetaRepository.
Now, to import filtered models we need to adapt classes such as FMImporter.
I can have a look on that and let you know.
What do you think?
regards,
On Wed, Nov 16, 2011 at 3:44 PM, Andre Hora <andrehoraa(a)gmail.com> wrote:
Hello Santiago,
You can find the custom loader Stef cited in: HoraExpTemp3 in SqueakSource
(load all the packages not related to Hismo). Then go to the Moose Panel
and click in "Import model from model from MSE file with context".
In fact I just fixed the wizard MooseImportFromMseWizard and used the
already implemented classes FMImporterFilter and FMParseClientFilter to
filter the model. The logic was already implemented.
regards,
So, the same idea we used to
On Mon, Nov 14, 2011 at 11:00 AM, Tudor Girba <tudor(a)tudorgirba.com>wrote;wrote:
--
Andre Hora
Hi,
On Mon, Nov 14, 2011 at 10:51 AM, Stéphane Ducasse <
stephane.ducasse(a)inria.fr> wrote:
--
Andre Hora
On Nov 14, 2011, at 7:59 AM, Tudor Girba wrote:
We have them in the form of property declared types. Furthermore, we also
take into account the derived information. So, if a property is derived, we
do not take it into account when computing the dependencies.
It works quite well. The only problem is that when the declared type is
generic we have to include in the dependencies all the subclasses. For
example, the type of inheritance superclass is Type, and this means that if
we want to load inheritances, we have to consider all entities that are
subclasses of Type (FAMIXClass, FAMIXTypeAlias ...).
This works well in almost all cases. The problem is with
annotationInstances which point to FAMIXEntity. So, currently, if you want
to load an annotation instance, you will end up loading the entire famix. I
guess we have to revisit the type of annotation instance to maybe be only a
named entity.
The consistency is achieved by having a filtering
mechanism that works
based on the information from the meta-model. When you filter
by saying
that you only want classes, the filter will produce a consistent but
smaller meta-model that will contain what is needed for the class to be
appropriately described.
I think there is still one issue left in the algorithm, but first we
should see
how it performs on larger case studies.
In any case, one side-effect is that the information from the
ImportingContext
should not be needed anymore because we could finally
reuse the one from the original meta-descriptions.
Ok but then it means that you should have the dependencies expressed
clearly at the meta model.
and remove importingContext.
Because having two mechanisms is not a good idea
on the long term.
Exactly :).
Doru
Stef
--
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
Cheers,
Doru
On 13 Nov 2011, at 23:13, Stéphane Ducasse wrote:
> I want to know in particular how the consistency of the resulting
model is
handled.
>
>
>> Thanks :).
>>
>> Andre, when you come back, we should pick up where we left and look
into
the integration of the Fame filter in Moose.
>>
>> Cheers,
>> Doru
>>
>>
>> On 13 Nov 2011, at 21:39, Nicolas Anquetil wrote:
>>
>>> FYI
>>>
>>> andre is on holiday till Wednesday
>>>
>>> nicolas
>>>
>>> ----- Mail original -----
>>>> De: "Tudor Girba" <tudor(a)tudorgirba.com>
>>>> À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
>>>> Envoyé: Dimanche 13 Novembre 2011 21:22:06
>>>> Objet: [Moose-dev] Re: Help with VerveineJ
>>>> +1.
>>>>
>>>> We now have the basic mechanism for loading partial models. But, I
>>>> will let Andre answer more details.
>>>>
>>>> Andre, you have the floor :)
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>>
>>>> On 13 Nov 2011, at 16:12, Stéphane Ducasse wrote:
>>>>
>>>>> If I remember Andre did a custom mse loader that can filter
entities
>>>>> to be loaded.
>>>>> Now I will wait for his answer
>>>>>
>>>>> In general this is a good idea to extract at maximum level and to
>>>>> filter while loading.
>>>>>
>>>>> Stef
>>>>>
>>>>> On Nov 11, 2011, at 7:43 PM, Santiago Vidal wrote:
>>>>>
>>>>>> Hi,
>>>>>> I had create several MSE files of different versions of a Java
>>>>>> system using VerveineJ. Then, I had tried to load them to the
Moose
>>>>>> Panel but after load two
of them I run out of memory in Moose
(The
>>>>>> Pharo error is
"Space is Low").
>>>>>> I had the same problem when loading several versions of Mondrian
to
>>>>>> Moose Panel. However, we
solved it by using the following script
>>>>>> (we select only those thing in which we are interested):
>>>>>>
>>>>>> | mooseModel packages task |
>>>>>>
>>>>>> #('2.10' '2.13' '2.100') do: [:version |
>>>>>> | project |
>>>>>> project := (ConfigurationOfMondrian project version:
>>>>>> version).
>>>>>>
>>>>>> [
>>>>>> project load.
>>>>>>
>>>>>> "This is necessary by Moose to properly
import"
>>>>>> Gofer new
>>>>>> url:
>>>>>> '
http://www.squeaksource.com/CollectionExtensions'#39;;
>>>>>>
version:
>>>>>> 'CollectionExtensions-TudorGirba.29';
>>>>>> load.
>>>>>>
>>>>>> packages := (project packages collect: #name) select:
>>>>>> [:p | p beginsWith: 'Mondrian'].
>>>>>> mooseModel := MooseModel new.
>>>>>> task := MooseSqueakClassCategoryImporterTask new.
>>>>>> task importerClass: SmalltalkImporter.
>>>>>> task importingContext mergeClassAndMetaclass.
>>>>>> task model: mooseModel.
>>>>>> task runCandidateOperator.
>>>>>> task addFromPackagesNamed: packages.
>>>>>> task runWithProgress.
>>>>>>
>>>>>> mooseModel name: 'Mondrian ', version.
>>>>>> mooseModel allMethods do: #numberOfLinesOfCode.
>>>>>> mooseModel install.
>>>>>> ] on: Error do: [ :ex | self halt. Transcript show:
'cannot
>>>>>> load version ', version, ' ', ex printString. ].
>>>>>> ]
>>>>>>
>>>>>> Is there any way to do the same with VerveineJ (that is, reduce
the
>>>>>> size of the MSE files)?
Or is there a way to expand the memory of
>>>>>> Moose?
>>>>>> Thanks
>>>>>>
>>>>>> --
>>>>>> Santiago Vidal
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>> "One cannot do more than one can do."
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> "In a world where everything is moving ever faster,
>> one might have better chances to win by moving slower."
>>
>>
>>
>>
>> _______________________________________________
>> 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
"Presenting is storytelling."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4:29 p.m.
Hi Andre,
On Wed, Nov 16, 2011 at 3:49 PM, Andre Hora <andrehoraa(a)gmail.com> wrote:
Hello,
As I said in the previous email we have a filtered loader working ok where I
basically reused some classes. The implementation is based on a
importContext to filter the imported model.
However, I am not sure if it is the best implementation because we are using
a separated filter (the context) but the filter should be the meta-model
(i.e., we should use FMMetaRepositoryFilter, the same we did with the
filtered exporter). Like that I guess we can even remove the classes
FMImporterFilter and FMParseClientFilter.
So, Doru, to use our implemented FMMetaRepositoryFilter to export filtered
models, you remember that we needed to adapt the classes
FMRepositoryVisitor, FMRepository and FMMetaRepository.
Now, to import filtered models we need to adapt classes such as FMImporter.
I can have a look on that and let you know.
We do not want to touch the FMImporter. The whole point of the filter
is so that we can pass to the importer a sub-meta-model and then it
does the job out of the box.
What we want is to translate the current ImportingContext into the
data for the FMMetaRepositoryFilter. As a later step, we can remove
the internal model of the ImportingContext altogether and use instead
directly a meta-repository. The API of the importing context should
remain because it is used in the Smalltalk importer.
What do you say?
Cheers,
Doru
What do you think?
regards,
On Wed, Nov 16, 2011 at 3:44 PM, Andre Hora <andrehoraa(a)gmail.com> wrote:
--
www.tudorgirba.com
"Every thing has its own flow"
Hello Santiago,
You can find the custom loader Stef cited in: HoraExpTemp3 in SqueakSource
(load all the packages not related to Hismo). Then go to the Moose Panel and
click in "Import model from model from MSE file with context".
In fact I just fixed the wizard MooseImportFromMseWizard and used the
already implemented classes FMImporterFilter and FMParseClientFilter to
filter the model. The logic was already implemented.
regards,
So, the same idea we used to
On Mon, Nov 14, 2011 at 11:00 AM, Tudor Girba <tudor(a)tudorgirba.com>
wrote:
--
Andre Hora
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
On Mon, Nov 14, 2011 at 10:51 AM, Stéphane Ducasse
<stephane.ducasse(a)inria.fr> wrote:
--
Andre Hora
On Nov 14, 2011, at 7:59 AM, Tudor Girba wrote:
> The consistency is achieved by having a filtering mechanism that works
> based on the information from the meta-model. When you filter by saying that
> you only want classes, the filter will produce a consistent but smaller
> meta-model that will contain what is needed for the class to be
> appropriately described.
>
> I think there is still one issue left in the algorithm, but first we
> should see how it performs on larger case studies.
>
> In any case, one side-effect is that the information from the
> ImportingContext should not be needed anymore because we could finally reuse
> the one from the original meta-descriptions.
Ok but then it means that you should have the dependencies expressed
clearly at the meta model.
and remove importingContext.
We have them in the form of property declared types. Furthermore, we also
take into account the derived information. So, if a property is derived, we
do not take it into account when computing the dependencies.
It works quite well. The only problem is that when the declared type is
generic we have to include in the dependencies all the subclasses. For
example, the type of inheritance superclass is Type, and this means that if
we want to load inheritances, we have to consider all entities that are
subclasses of Type (FAMIXClass, FAMIXTypeAlias ...).
This works well in almost all cases. The problem is with
annotationInstances which point to FAMIXEntity. So, currently, if you want
to load an annotation instance, you will end up loading the entire famix. I
guess we have to revisit the type of annotation instance to maybe be only a
named entity.
Because having two mechanisms is not a good idea on the long term.
Exactly :).
Doru
Stef
>
> Cheers,
> Doru
>
>
> On 13 Nov 2011, at 23:13, Stéphane Ducasse wrote:
>
>> I want to know in particular how the consistency of the resulting
>> model is handled.
>>
>>
>>> Thanks :).
>>>
>>> Andre, when you come back, we should pick up where we left and look
>>> into the integration of the Fame filter in Moose.
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>> On 13 Nov 2011, at 21:39, Nicolas Anquetil wrote:
>>>
>>>> FYI
>>>>
>>>> andre is on holiday till Wednesday
>>>>
>>>> nicolas
>>>>
>>>> ----- Mail original -----
>>>>> De: "Tudor Girba" <tudor(a)tudorgirba.com>
>>>>> À: "Moose-related development"
<moose-dev(a)iam.unibe.ch>
>>>>> Envoyé: Dimanche 13 Novembre 2011 21:22:06
>>>>> Objet: [Moose-dev] Re: Help with VerveineJ
>>>>> +1.
>>>>>
>>>>> We now have the basic mechanism for loading partial models. But, I
>>>>> will let Andre answer more details.
>>>>>
>>>>> Andre, you have the floor :)
>>>>>
>>>>> Cheers,
>>>>> Doru
>>>>>
>>>>>
>>>>> On 13 Nov 2011, at 16:12, Stéphane Ducasse wrote:
>>>>>
>>>>>> If I remember Andre did a custom mse loader that can filter
>>>>>> entities
>>>>>> to be loaded.
>>>>>> Now I will wait for his answer
>>>>>>
>>>>>> In general this is a good idea to extract at maximum level and
to
>>>>>> filter while loading.
>>>>>>
>>>>>> Stef
>>>>>>
>>>>>> On Nov 11, 2011, at 7:43 PM, Santiago Vidal wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>> I had create several MSE files of different versions of a
Java
>>>>>>> system using VerveineJ. Then, I had tried to load them to
the
>>>>>>> Moose
>>>>>>> Panel but after load two of them I run out of memory in
Moose
>>>>>>> (The
>>>>>>> Pharo error is "Space is Low").
>>>>>>> I had the same problem when loading several versions of
Mondrian
>>>>>>> to
>>>>>>> Moose Panel. However, we solved it by using the following
script
>>>>>>> (we select only those thing in which we are interested):
>>>>>>>
>>>>>>> | mooseModel packages task |
>>>>>>>
>>>>>>> #('2.10' '2.13' '2.100') do:
[:version |
>>>>>>> | project |
>>>>>>> project := (ConfigurationOfMondrian project version:
>>>>>>> version).
>>>>>>>
>>>>>>> [
>>>>>>> project load.
>>>>>>>
>>>>>>> "This is necessary by Moose to properly
import"
>>>>>>> Gofer new
>>>>>>> url:
>>>>>>>
>>>>>>> 'http://www.squeaksource.com/CollectionExtensions';
>>>>>>> version:
>>>>>>>
'CollectionExtensions-TudorGirba.29';
>>>>>>> load.
>>>>>>>
>>>>>>> packages := (project packages collect: #name)
select:
>>>>>>> [:p | p beginsWith: 'Mondrian'].
>>>>>>> mooseModel := MooseModel new.
>>>>>>> task := MooseSqueakClassCategoryImporterTask new.
>>>>>>> task importerClass: SmalltalkImporter.
>>>>>>> task importingContext mergeClassAndMetaclass.
>>>>>>> task model: mooseModel.
>>>>>>> task runCandidateOperator.
>>>>>>> task addFromPackagesNamed: packages.
>>>>>>> task runWithProgress.
>>>>>>>
>>>>>>> mooseModel name: 'Mondrian ', version.
>>>>>>> mooseModel allMethods do: #numberOfLinesOfCode.
>>>>>>> mooseModel install.
>>>>>>> ] on: Error do: [ :ex | self halt. Transcript show:
'cannot
>>>>>>> load version ', version, ' ', ex printString.
].
>>>>>>> ]
>>>>>>>
>>>>>>> Is there any way to do the same with VerveineJ (that is,
reduce
>>>>>>> the
>>>>>>> size of the MSE files)? Or is there a way to expand the
memory
>>>>>>> of
>>>>>>> Moose?
>>>>>>> Thanks
>>>>>>>
>>>>>>> --
>>>>>>> Santiago Vidal
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>
>>>>> "One cannot do more than one can do."
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>> "In a world where everything is moving ever faster,
>>> one might have better chances to win by moving slower."
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
> "Presenting is storytelling."
>
>
> _______________________________________________
> 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
"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
5:41 p.m.
On Wed, Nov 16, 2011 at 4:29 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
Hi Andre,
On Wed, Nov 16, 2011 at 3:49 PM, Andre Hora <andrehoraa(a)gmail.com> wrote:
Which filter do mean? FMMetaRepositoryFilter or FMImporterFilter?
The point is that:
- for the exporter, now, we don't have a filter like for example
FMRepositoryVisitorFilter (what is OK). We filter with a filtered
meta-model.
- for the importer we have a filter FMImporterFilter. So, this is OK, but
strange :)
What we want is to translate the current ImportingContext into the
Hello,
As I said in the previous email we have a filtered loader working ok
where I
basically reused some classes. The implementation
is based on a
importContext to filter the imported model.
However, I am not sure if it is the best implementation because we are
using
a separated filter (the context) but the filter
should be the meta-model
(i.e., we should use FMMetaRepositoryFilter, the same we did with the
filtered exporter). Like that I guess we can even remove the classes
FMImporterFilter and FMParseClientFilter.
So, Doru, to use our implemented FMMetaRepositoryFilter to export
filtered
models, you remember that we needed to adapt the
classes
FMRepositoryVisitor, FMRepository and FMMetaRepository.
Now, to import filtered models we need to adapt classes such as
FMImporter.
I can have a look on that and let you know.
We do not want to touch the FMImporter. The whole point of the filter
is so that we can pass to the importer a sub-meta-model and then it
does the job out of the box.
data for the FMMetaRepositoryFilter.
As a later step, we can remove the internal model of the ImportingContext
altogether and use instead
directly a meta-repository.
Yes, I stared to do that with the AutomaticMooseImportingContext. I will
return to that.
The API of the importing context should
remain because it is used in the Smalltalk importer.
ok!
What do you say?
Cheers,
Doru
--
Andre Hora
_______________________________________________
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
--
Andre Hora
What do you think?
regards,
On Wed, Nov 16, 2011 at 3:44 PM, Andre Hora <andrehoraa(a)gmail.com>
wrote:
>
> Hello Santiago,
>
> You can find the custom loader Stef cited in: HoraExpTemp3 in
SqueakSource
> (load all the packages not related to Hismo).
Then go to the Moose
Panel and
> click in "Import model from model from
MSE file with context".
> In fact I just fixed the wizard MooseImportFromMseWizard and used the
> already implemented classes FMImporterFilter and FMParseClientFilter to
> filter the model. The logic was already implemented.
>
> regards,
>
> So, the same idea we used to
>
>
> On Mon, Nov 14, 2011 at 11:00 AM, Tudor Girba <tudor(a)tudorgirba.com>
> wrote:
>>
>> Hi,
>>
>> On Mon, Nov 14, 2011 at 10:51 AM, Stéphane Ducasse
>> <stephane.ducasse(a)inria.fr> wrote:
>>>
>>> On Nov 14, 2011, at 7:59 AM, Tudor Girba wrote:
>>>
>>> > The consistency is achieved by having a filtering mechanism that
works
>>> > based on the information from
the meta-model. When you filter by
saying that
>>> > you only want classes, the
filter will produce a consistent but
smaller
>>> > meta-model that will contain
what is needed for the class to be
>>> > appropriately described.
>>> >
>>> > I think there is still one issue left in the algorithm, but first we
>>> > should see how it performs on larger case studies.
>>> >
>>> > In any case, one side-effect is that the information from the
>>> > ImportingContext should not be needed anymore because we could
finally reuse
>>> > the one from the original
meta-descriptions.
>>>
>>>
>>> Ok but then it means that you should have the dependencies expressed
>>> clearly at the meta model.
>>> and remove importingContext.
>>
>> We have them in the form of property declared types. Furthermore, we
also
>> take into account the derived
information. So, if a property is
derived, we
>> do not take it into account when
computing the dependencies.
>> It works quite well. The only problem is that when the declared type is
>> generic we have to include in the dependencies all the subclasses. For
>> example, the type of inheritance superclass is Type, and this means
that
if
>> we want to load inheritances, we have to
consider all entities that are
>> subclasses of Type (FAMIXClass, FAMIXTypeAlias ...).
>> This works well in almost all cases. The problem is with
>> annotationInstances which point to FAMIXEntity. So, currently, if you
want
>> to load an annotation instance, you will
end up loading the entire
famix. I
>> guess we have to revisit the type of
annotation instance to maybe be
only a
>> named entity.
>>
>>>
>>> Because having two mechanisms is not a good idea on the long term.
>>
>> Exactly :).
>> Doru
>>
>>>
>>> Stef
>>> >
>>> > Cheers,
>>> > Doru
>>> >
>>> >
>>> > On 13 Nov 2011, at 23:13, Stéphane Ducasse wrote:
>>> >
>>> >> I want to know in particular how the consistency of the resulting
>>> >> model is handled.
>>> >>
>>> >>
>>> >>> Thanks :).
>>> >>>
>>> >>> Andre, when you come back, we should pick up where we left and
look
>>> >>> into the integration of
the Fame filter in Moose.
>>> >>>
>>> >>> Cheers,
>>> >>> Doru
>>> >>>
>>> >>>
>>> >>> On 13 Nov 2011, at 21:39, Nicolas Anquetil wrote:
>>> >>>
>>> >>>> FYI
>>> >>>>
>>> >>>> andre is on holiday till Wednesday
>>> >>>>
>>> >>>> nicolas
>>> >>>>
>>> >>>> ----- Mail original -----
>>> >>>>> De: "Tudor Girba"
<tudor(a)tudorgirba.com>
>>> >>>>> À: "Moose-related development"
<moose-dev(a)iam.unibe.ch>
>>> >>>>> Envoyé: Dimanche 13 Novembre 2011 21:22:06
>>> >>>>> Objet: [Moose-dev] Re: Help with VerveineJ
>>> >>>>> +1.
>>> >>>>>
>>> >>>>> We now have the basic mechanism for loading partial
models.
But, I
>>> >>>>> will let Andre
answer more details.
>>> >>>>>
>>> >>>>> Andre, you have the floor :)
>>> >>>>>
>>> >>>>> Cheers,
>>> >>>>> Doru
>>> >>>>>
>>> >>>>>
>>> >>>>> On 13 Nov 2011, at 16:12, Stéphane Ducasse wrote:
>>> >>>>>
>>> >>>>>> If I remember Andre did a custom mse loader that can
filter
>>> >>>>>> entities
>>> >>>>>> to be loaded.
>>> >>>>>> Now I will wait for his answer
>>> >>>>>>
>>> >>>>>> In general this is a good idea to extract at maximum
level and
to
>>> >>>>>> filter while
loading.
>>> >>>>>>
>>> >>>>>> Stef
>>> >>>>>>
>>> >>>>>> On Nov 11, 2011, at 7:43 PM, Santiago Vidal wrote:
>>> >>>>>>
>>> >>>>>>> Hi,
>>> >>>>>>> I had create several MSE files of different
versions of a Java
>>> >>>>>>> system using VerveineJ. Then, I had tried to
load them to the
>>> >>>>>>> Moose
>>> >>>>>>> Panel but after load two of them I run out of
memory in Moose
>>> >>>>>>> (The
>>> >>>>>>> Pharo error is "Space is Low").
>>> >>>>>>> I had the same problem when loading several
versions of
Mondrian
>>> >>>>>>> to
>>> >>>>>>> Moose Panel. However, we solved it by using the
following
script
>>> >>>>>>> (we
select only those thing in which we are interested):
>>> >>>>>>>
>>> >>>>>>> | mooseModel packages task |
>>> >>>>>>>
>>> >>>>>>> #('2.10' '2.13' '2.100')
do: [:version |
>>> >>>>>>> | project |
>>> >>>>>>> project := (ConfigurationOfMondrian project
version:
>>> >>>>>>> version).
>>> >>>>>>>
>>> >>>>>>> [
>>> >>>>>>> project load.
>>> >>>>>>>
>>> >>>>>>> "This is necessary by Moose to
properly import"
>>> >>>>>>> Gofer new
>>> >>>>>>> url:
>>> >>>>>>>
>>> >>>>>>>
'http://www.squeaksource.com/CollectionExtensions';
>>> >>>>>>> version:
>>> >>>>>>>
'CollectionExtensions-TudorGirba.29';
>>> >>>>>>> load.
>>> >>>>>>>
>>> >>>>>>> packages := (project packages collect:
#name)
select:
>>> >>>>>>>
[:p | p beginsWith: 'Mondrian'].
>>> >>>>>>> mooseModel := MooseModel new.
>>> >>>>>>> task :=
MooseSqueakClassCategoryImporterTask new.
>>> >>>>>>> task importerClass:
SmalltalkImporter.
>>> >>>>>>> task importingContext
mergeClassAndMetaclass.
>>> >>>>>>> task model: mooseModel.
>>> >>>>>>> task runCandidateOperator.
>>> >>>>>>> task addFromPackagesNamed: packages.
>>> >>>>>>> task runWithProgress.
>>> >>>>>>>
>>> >>>>>>> mooseModel name: 'Mondrian ',
version.
>>> >>>>>>> mooseModel allMethods do:
#numberOfLinesOfCode.
>>> >>>>>>> mooseModel install.
>>> >>>>>>> ] on: Error do: [ :ex | self halt. Transcript
show: 'cannot
>>> >>>>>>> load version ', version, ' ', ex
printString. ].
>>> >>>>>>> ]
>>> >>>>>>>
>>> >>>>>>> Is there any way to do the same with VerveineJ
(that is,
reduce
> >>>>>>> the
> >>>>>>> size of the MSE files)? Or is there a way to expand the
memory
> >>>>>>> of
> >>>>>>> Moose?
> >>>>>>> Thanks
> >>>>>>>
> >>>>>>> --
> >>>>>>> Santiago Vidal
> >>>>>>> _______________________________________________
> >>>>>>> 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
> >>>>>
> >>>>> "One cannot do more than one can do."
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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
> >>>
> >>> "In a world where everything is moving ever faster,
> >>> one might have better chances to win by moving slower."
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
> >
> > "Presenting is storytelling."
> >
> >
> > _______________________________________________
> > 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
"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
--
Andre Hora
5:48 p.m.
Hi,
On Wed, Nov 16, 2011 at 5:41 PM, Andre Hora <andrehoraa(a)gmail.com> wrote:
--
www.tudorgirba.com
"Every thing has its own flow"
On Wed, Nov 16, 2011 at 4:29 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
This is not Ok. The FMImporterFilter should not be needed. We should
only need to pass the right meta repository, and the partial model
gets loaded. The only thing is that we have to make the importer more
robust to not crash necessarily when it does not find an entity (this
is what can be done in a subclass).
Cheers,
Doru
Hi Andre,
On Wed, Nov 16, 2011 at 3:49 PM, Andre Hora <andrehoraa(a)gmail.com> wrote:
Which filter do mean? FMMetaRepositoryFilter or FMImporterFilter?
The point is that:
- for the exporter, now, we don't have a filter like for example
FMRepositoryVisitorFilter (what is OK). We filter with a filtered
meta-model.
- for the importer we have a filter FMImporterFilter. So, this is OK, but
strange :) Hello,
As I said in the previous email we have a filtered loader working ok
where I
basically reused some classes. The implementation is based on a
importContext to filter the imported model.
However, I am not sure if it is the best implementation because we are
using
a separated filter (the context) but the filter should be the meta-model
(i.e., we should use FMMetaRepositoryFilter, the same we did with the
filtered exporter). Like that I guess we can even remove the classes
FMImporterFilter and FMParseClientFilter.
So, Doru, to use our implemented FMMetaRepositoryFilter to export
filtered
models, you remember that we needed to adapt the classes
FMRepositoryVisitor, FMRepository and FMMetaRepository.
Now, to import filtered models we need to adapt classes such as
FMImporter.
I can have a look on that and let you know.
We do not want to touch the FMImporter. The whole point of the filter
is so that we can pass to the importer a sub-meta-model and then it
does the job out of the box.
What we want is to translate the current ImportingContext into the
data for the FMMetaRepositoryFilter.
As a later step, we can remove the internal model of the ImportingContext
altogether and use instead
directly a meta-repository.
Yes, I stared to do that with the AutomaticMooseImportingContext. I will
return to that.
The API of the importing context should
remain because it is used in the Smalltalk importer.
ok!
What do you say?
Cheers,
Doru
--
Andre Hora
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
What do you think?
regards,
On Wed, Nov 16, 2011 at 3:44 PM, Andre Hora <andrehoraa(a)gmail.com>
wrote:
--
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
Hello Santiago,
You can find the custom loader Stef cited in: HoraExpTemp3 in
SqueakSource
(load all the packages not related to Hismo). Then go to the Moose
Panel and
click in "Import model from model from MSE file with context".
In fact I just fixed the wizard MooseImportFromMseWizard and used the
already implemented classes FMImporterFilter and FMParseClientFilter to
filter the model. The logic was already implemented.
regards,
So, the same idea we used to
On Mon, Nov 14, 2011 at 11:00 AM, Tudor Girba <tudor(a)tudorgirba.com>
wrote:
>
> Hi,
>
> On Mon, Nov 14, 2011 at 10:51 AM, Stéphane Ducasse
> <stephane.ducasse(a)inria.fr> wrote:
>>
>> On Nov 14, 2011, at 7:59 AM, Tudor Girba wrote:
>>
>> > The consistency is achieved by having a filtering mechanism that
>> > works
>> > based on the information from the meta-model. When you filter by
>> > saying that
>> > you only want classes, the filter will produce a consistent but
>> > smaller
>> > meta-model that will contain what is needed for the class to be
>> > appropriately described.
>> >
>> > I think there is still one issue left in the algorithm, but first
>> > we
>> > should see how it performs on larger case studies.
>> >
>> > In any case, one side-effect is that the information from the
>> > ImportingContext should not be needed anymore because we could
>> > finally reuse
>> > the one from the original meta-descriptions.
>>
>>
>> Ok but then it means that you should have the dependencies expressed
>> clearly at the meta model.
>> and remove importingContext.
>
> We have them in the form of property declared types. Furthermore, we
> also
> take into account the derived information. So, if a property is
> derived, we
> do not take it into account when computing the dependencies.
> It works quite well. The only problem is that when the declared type
> is
> generic we have to include in the dependencies all the subclasses. For
> example, the type of inheritance superclass is Type, and this means
> that if
> we want to load inheritances, we have to consider all entities that
> are
> subclasses of Type (FAMIXClass, FAMIXTypeAlias ...).
> This works well in almost all cases. The problem is with
> annotationInstances which point to FAMIXEntity. So, currently, if you
> want
> to load an annotation instance, you will end up loading the entire
> famix. I
> guess we have to revisit the type of annotation instance to maybe be
> only a
> named entity.
>
>>
>> Because having two mechanisms is not a good idea on the long term.
>
> Exactly :).
> Doru
>
>>
>> Stef
>> >
>> > Cheers,
>> > Doru
>> >
>> >
>> > On 13 Nov 2011, at 23:13, Stéphane Ducasse wrote:
>> >
>> >> I want to know in particular how the consistency of the resulting
>> >> model is handled.
>> >>
>> >>
>> >>> Thanks :).
>> >>>
>> >>> Andre, when you come back, we should pick up where we left and
>> >>> look
>> >>> into the integration of the Fame filter in Moose.
>> >>>
>> >>> Cheers,
>> >>> Doru
>> >>>
>> >>>
>> >>> On 13 Nov 2011, at 21:39, Nicolas Anquetil wrote:
>> >>>
>> >>>> FYI
>> >>>>
>> >>>> andre is on holiday till Wednesday
>> >>>>
>> >>>> nicolas
>> >>>>
>> >>>> ----- Mail original -----
>> >>>>> De: "Tudor Girba" <tudor(a)tudorgirba.com>
>> >>>>> À: "Moose-related development"
<moose-dev(a)iam.unibe.ch>
>> >>>>> Envoyé: Dimanche 13 Novembre 2011 21:22:06
>> >>>>> Objet: [Moose-dev] Re: Help with VerveineJ
>> >>>>> +1.
>> >>>>>
>> >>>>> We now have the basic mechanism for loading partial models.
>> >>>>> But, I
>> >>>>> will let Andre answer more details.
>> >>>>>
>> >>>>> Andre, you have the floor :)
>> >>>>>
>> >>>>> Cheers,
>> >>>>> Doru
>> >>>>>
>> >>>>>
>> >>>>> On 13 Nov 2011, at 16:12, Stéphane Ducasse wrote:
>> >>>>>
>> >>>>>> If I remember Andre did a custom mse loader that can
filter
>> >>>>>> entities
>> >>>>>> to be loaded.
>> >>>>>> Now I will wait for his answer
>> >>>>>>
>> >>>>>> In general this is a good idea to extract at maximum
level and
>> >>>>>> to
>> >>>>>> filter while loading.
>> >>>>>>
>> >>>>>> Stef
>> >>>>>>
>> >>>>>> On Nov 11, 2011, at 7:43 PM, Santiago Vidal wrote:
>> >>>>>>
>> >>>>>>> Hi,
>> >>>>>>> I had create several MSE files of different versions
of a
>> >>>>>>> Java
>> >>>>>>> system using VerveineJ. Then, I had tried to load
them to the
>> >>>>>>> Moose
>> >>>>>>> Panel but after load two of them I run out of memory
in Moose
>> >>>>>>> (The
>> >>>>>>> Pharo error is "Space is Low").
>> >>>>>>> I had the same problem when loading several versions
of
>> >>>>>>> Mondrian
>> >>>>>>> to
>> >>>>>>> Moose Panel. However, we solved it by using the
following
>> >>>>>>> script
>> >>>>>>> (we select only those thing in which we are
interested):
>> >>>>>>>
>> >>>>>>> | mooseModel packages task |
>> >>>>>>>
>> >>>>>>> #('2.10' '2.13' '2.100') do:
[:version |
>> >>>>>>> | project |
>> >>>>>>> project := (ConfigurationOfMondrian project
version:
>> >>>>>>> version).
>> >>>>>>>
>> >>>>>>> [
>> >>>>>>> project load.
>> >>>>>>>
>> >>>>>>> "This is necessary by Moose to
properly import"
>> >>>>>>> Gofer new
>> >>>>>>> url:
>> >>>>>>>
>> >>>>>>>
'http://www.squeaksource.com/CollectionExtensions';
>> >>>>>>> version:
>> >>>>>>>
'CollectionExtensions-TudorGirba.29';
>> >>>>>>> load.
>> >>>>>>>
>> >>>>>>> packages := (project packages collect:
#name)
>> >>>>>>> select:
>> >>>>>>> [:p | p beginsWith: 'Mondrian'].
>> >>>>>>> mooseModel := MooseModel new.
>> >>>>>>> task :=
MooseSqueakClassCategoryImporterTask new.
>> >>>>>>> task importerClass: SmalltalkImporter.
>> >>>>>>> task importingContext
mergeClassAndMetaclass.
>> >>>>>>> task model: mooseModel.
>> >>>>>>> task runCandidateOperator.
>> >>>>>>> task addFromPackagesNamed: packages.
>> >>>>>>> task runWithProgress.
>> >>>>>>>
>> >>>>>>> mooseModel name: 'Mondrian ',
version.
>> >>>>>>> mooseModel allMethods do:
#numberOfLinesOfCode.
>> >>>>>>> mooseModel install.
>> >>>>>>> ] on: Error do: [ :ex | self halt. Transcript
show: 'cannot
>> >>>>>>> load version ', version, ' ', ex
printString. ].
>> >>>>>>> ]
>> >>>>>>>
>> >>>>>>> Is there any way to do the same with VerveineJ (that
is,
>> >>>>>>> reduce
>> >>>>>>> the
>> >>>>>>> size of the MSE files)? Or is there a way to expand
the
>> >>>>>>> memory
>> >>>>>>> of
>> >>>>>>> Moose?
>> >>>>>>> Thanks
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>> Santiago Vidal
>> >>>>>>> _______________________________________________
>> >>>>>>> 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
>> >>>>>
>> >>>>> "One cannot do more than one can do."
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> 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
>> >>>
>> >>> "In a world where everything is moving ever faster,
>> >>> one might have better chances to win by moving slower."
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> 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
>> >
>> > "Presenting is storytelling."
>> >
>> >
>> > _______________________________________________
>> > 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
> "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
>
--
Andre Hora
--
Andre Hora
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
6:22 p.m.
On Wed, Nov 16, 2011 at 5:48 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
Hi,
On Wed, Nov 16, 2011 at 5:41 PM, Andre Hora <andrehoraa(a)gmail.com> wrote:
Which filter do mean? FMMetaRepositoryFilter or FMImporterFilter?
The point is that:
- for the exporter, now, we don't have a filter like for example
FMRepositoryVisitorFilter (what is OK). We filter with a filtered
meta-model.
- for the importer we have a filter FMImporterFilter. So, this is OK, but
strange :)
This is not Ok. The FMImporterFilter should not be needed. We should
only need to pass the right meta repository, and the partial model
gets loaded.
Yes, that's what I suggested in the first email :)
On Wed, Nov 16, 2011 at 4:29 PM, Tudor Girba <tudor(a)tudorgirba.com>
wrote:
>
> Hi Andre,
>
> On Wed, Nov 16, 2011 at 3:49 PM, Andre Hora <andrehoraa(a)gmail.com>
wrote:
> > Hello,
> >
> > As I said in the previous email we have a filtered loader working ok
> > where I
> > basically reused some classes. The implementation is based on a
> > importContext to filter the imported model.
> > However, I am not sure if it is the best implementation because we are
> > using
> > a separated filter (the context) but the filter should be the
meta-model
(i.e., we should use FMMetaRepositoryFilter, the same
we did with the
filtered exporter). Like that I guess we can even remove the classes
FMImporterFilter and FMParseClientFilter.
So, Doru, to use our implemented FMMetaRepositoryFilter to export
filtered
models, you remember that we needed to adapt the classes
FMRepositoryVisitor, FMRepository and FMMetaRepository.
Now, to import filtered models we need to adapt classes such as
FMImporter.
I can have a look on that and let you know.
We do not want to touch the FMImporter. The whole point of the filter
is so that we can pass to the importer a sub-meta-model and then it
does the job out of the box. The only thing is that we have to make the importer
more
robust to not crash necessarily when it does not find an entity (this
is what can be done in a subclass).
Cheers,
Doru
to
--
Andre Hora
_______________________________________________
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
--
Andre Hora
>
>
> What we want is to translate the current ImportingContext into the
> data for the FMMetaRepositoryFilter.
>
> As a later step, we can remove the internal model of the
ImportingContext
altogether and use instead
directly a meta-repository.
Yes, I stared to do that with the AutomaticMooseImportingContext. I will
return to that.
The API of the importing context should
remain because it is used in the Smalltalk importer.
ok!
>
> What do you say?
>
> Cheers,
> Doru
>
> > What do you think?
> >
> > regards,
> >
> > On Wed, Nov 16, 2011 at 3:44 PM, Andre Hora <andrehoraa(a)gmail.com>
> > wrote:
> >>
> >> Hello Santiago,
> >>
> >> You can find the custom loader Stef cited in: HoraExpTemp3 in
> >> SqueakSource
> >> (load all the packages not related to Hismo). Then go to the Moose
> >> Panel and
> >> click in "Import model from model from MSE file with context".
> >> In fact I just fixed the wizard MooseImportFromMseWizard and used the
> >> already implemented classes FMImporterFilter and FMParseClientFilter > >> filter the model. The logic was
already implemented.
> >>
> >> regards,
> >>
> >> So, the same idea we used to
> >>
> >>
> >> On Mon, Nov 14, 2011 at 11:00 AM, Tudor Girba <tudor(a)tudorgirba.com>
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Mon, Nov 14, 2011 at 10:51 AM, Stéphane Ducasse
> >>> <stephane.ducasse(a)inria.fr> wrote:
> >>>>
> >>>> On Nov 14, 2011, at 7:59 AM, Tudor Girba wrote:
> >>>>
> >>>> > The consistency is achieved by having a filtering mechanism
that
> >>>> > works
> >>>> > based on the information from the meta-model. When you filter
by
> >>>> > saying that
> >>>> > you only want classes, the filter will produce a consistent
but
> >>>> > smaller
> >>>> > meta-model that will contain what is needed for the class to
be
> >>>> > appropriately described.
> >>>> >
> >>>> > I think there is still one issue left in the algorithm, but
first
> >>>> > we
> >>>> > should see how it performs on larger case studies.
> >>>> >
> >>>> > In any case, one side-effect is that the information from the
> >>>> > ImportingContext should not be needed anymore because we could
> >>>> > finally reuse
> >>>> > the one from the original meta-descriptions.
> >>>>
> >>>>
> >>>> Ok but then it means that you should have the dependencies
expressed
> >>>> clearly at the meta model.
> >>>> and remove importingContext.
> >>>
> >>> We have them in the form of property declared types. Furthermore, we
> >>> also
> >>> take into account the derived information. So, if a property is
> >>> derived, we
> >>> do not take it into account when computing the dependencies.
> >>> It works quite well. The only problem is that when the declared type
> >>> is
> >>> generic we have to include in the dependencies all the subclasses.
For
> >>> example, the type of inheritance
superclass is Type, and this means
> >>> that if
> >>> we want to load inheritances, we have to consider all entities that
> >>> are
> >>> subclasses of Type (FAMIXClass, FAMIXTypeAlias ...).
> >>> This works well in almost all cases. The problem is with
> >>> annotationInstances which point to FAMIXEntity. So, currently, if
you
> >>> want
> >>> to load an annotation instance, you will end up loading the entire
> >>> famix. I
> >>> guess we have to revisit the type of annotation instance to maybe be
> >>> only a
> >>> named entity.
> >>>
> >>>>
> >>>> Because having two mechanisms is not a good idea on the long term.
> >>>
> >>> Exactly :).
> >>> Doru
> >>>
> >>>>
> >>>> Stef
> >>>> >
> >>>> > Cheers,
> >>>> > Doru
> >>>> >
> >>>> >
> >>>> > On 13 Nov 2011, at 23:13, Stéphane Ducasse wrote:
> >>>> >
> >>>> >> I want to know in particular how the consistency of the
resulting
> >>>> >> model is handled.
> >>>> >>
> >>>> >>
> >>>> >>> Thanks :).
> >>>> >>>
> >>>> >>> Andre, when you come back, we should pick up where we
left and
> >>>> >>> look
> >>>> >>> into the integration of the Fame filter in Moose.
> >>>> >>>
> >>>> >>> Cheers,
> >>>> >>> Doru
> >>>> >>>
> >>>> >>>
> >>>> >>> On 13 Nov 2011, at 21:39, Nicolas Anquetil wrote:
> >>>> >>>
> >>>> >>>> FYI
> >>>> >>>>
> >>>> >>>> andre is on holiday till Wednesday
> >>>> >>>>
> >>>> >>>> nicolas
> >>>> >>>>
> >>>> >>>> ----- Mail original -----
> >>>> >>>>> De: "Tudor Girba"
<tudor(a)tudorgirba.com>
> >>>> >>>>> À: "Moose-related development"
<moose-dev(a)iam.unibe.ch>
> >>>> >>>>> Envoyé: Dimanche 13 Novembre 2011 21:22:06
> >>>> >>>>> Objet: [Moose-dev] Re: Help with VerveineJ
> >>>> >>>>> +1.
> >>>> >>>>>
> >>>> >>>>> We now have the basic mechanism for loading
partial models.
> >>>> >>>>> But, I
> >>>> >>>>> will let Andre answer more details.
> >>>> >>>>>
> >>>> >>>>> Andre, you have the floor :)
> >>>> >>>>>
> >>>> >>>>> Cheers,
> >>>> >>>>> Doru
> >>>> >>>>>
> >>>> >>>>>
> >>>> >>>>> On 13 Nov 2011, at 16:12, Stéphane Ducasse
wrote:
> >>>> >>>>>
> >>>> >>>>>> If I remember Andre did a custom mse loader
that can filter
> >>>> >>>>>> entities
> >>>> >>>>>> to be loaded.
> >>>> >>>>>> Now I will wait for his answer
> >>>> >>>>>>
> >>>> >>>>>> In general this is a good idea to extract
at maximum level
and
> >>>> >>>>>> to
> >>>> >>>>>> filter while loading.
> >>>> >>>>>>
> >>>> >>>>>> Stef
> >>>> >>>>>>
> >>>> >>>>>> On Nov 11, 2011, at 7:43 PM, Santiago Vidal
wrote:
> >>>> >>>>>>
> >>>> >>>>>>> Hi,
> >>>> >>>>>>> I had create several MSE files of
different versions of a
> >>>> >>>>>>> Java
> >>>> >>>>>>> system using VerveineJ. Then, I had
tried to load them to
the
> >>>> >>>>>>>
Moose
> >>>> >>>>>>> Panel but after load two of them I run
out of memory in
Moose
> >>>> >>>>>>>
(The
> >>>> >>>>>>> Pharo error is "Space is
Low").
> >>>> >>>>>>> I had the same problem when loading
several versions of
> >>>> >>>>>>> Mondrian
> >>>> >>>>>>> to
> >>>> >>>>>>> Moose Panel. However, we solved it by
using the following
> >>>> >>>>>>> script
> >>>> >>>>>>> (we select only those thing in which we
are interested):
> >>>> >>>>>>>
> >>>> >>>>>>> | mooseModel packages task |
> >>>> >>>>>>>
> >>>> >>>>>>> #('2.10' '2.13'
'2.100') do: [:version |
> >>>> >>>>>>> | project |
> >>>> >>>>>>> project := (ConfigurationOfMondrian
project version:
> >>>> >>>>>>> version).
> >>>> >>>>>>>
> >>>> >>>>>>> [
> >>>> >>>>>>> project load.
> >>>> >>>>>>>
> >>>> >>>>>>> "This is necessary by
Moose to properly import"
> >>>> >>>>>>> Gofer new
> >>>> >>>>>>> url:
> >>>> >>>>>>>
> >>>> >>>>>>>
'http://www.squeaksource.com/CollectionExtensions';
> >>>> >>>>>>> version:
> >>>> >>>>>>>
'CollectionExtensions-TudorGirba.29';
> >>>> >>>>>>> load.
> >>>> >>>>>>>
> >>>> >>>>>>> packages := (project packages
collect: #name)
> >>>> >>>>>>> select:
> >>>> >>>>>>> [:p | p beginsWith:
'Mondrian'].
> >>>> >>>>>>> mooseModel := MooseModel
new.
> >>>> >>>>>>> task :=
MooseSqueakClassCategoryImporterTask new.
> >>>> >>>>>>> task importerClass:
SmalltalkImporter.
> >>>> >>>>>>> task importingContext
mergeClassAndMetaclass.
> >>>> >>>>>>> task model: mooseModel.
> >>>> >>>>>>> task runCandidateOperator.
> >>>> >>>>>>> task addFromPackagesNamed:
packages.
> >>>> >>>>>>> task runWithProgress.
> >>>> >>>>>>>
> >>>> >>>>>>> mooseModel name:
'Mondrian ', version.
> >>>> >>>>>>> mooseModel allMethods do:
#numberOfLinesOfCode.
> >>>> >>>>>>> mooseModel install.
> >>>> >>>>>>> ] on: Error do: [ :ex | self halt.
Transcript show:
'cannot
>>> >>>>>>> load
version ', version, ' ', ex printString. ].
>>> >>>>>>> ]
>>> >>>>>>>
>>> >>>>>>> Is there any way to do the same with VerveineJ
(that is,
>>> >>>>>>> reduce
>>> >>>>>>> the
>>> >>>>>>> size of the MSE files)? Or is there a way to
expand the
>>> >>>>>>> memory
>>> >>>>>>> of
>>> >>>>>>> Moose?
>>> >>>>>>> Thanks
>>> >>>>>>>
>>> >>>>>>> --
>>> >>>>>>> Santiago Vidal
>>> >>>>>>> _______________________________________________
>>> >>>>>>> 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
>>> >>>>>
>>> >>>>> "One cannot do more than one can do."
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> _______________________________________________
>>> >>>>> 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
>>> >>>
>>> >>> "In a world where everything is moving ever faster,
>>> >>> one might have better chances to win by moving slower."
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> 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
>>> >
>>> > "Presenting is storytelling."
>>> >
>>> >
>>> > _______________________________________________
>>> > 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
>> "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
>>
>
>
>
> --
> Andre Hora
>
--
Andre Hora
_______________________________________________
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
17 Nov
17 Nov
7:58 p.m.
On Nov 16, 2011, at 4:29 PM, Tudor Girba wrote:
Hi Andre,
On Wed, Nov 16, 2011 at 3:49 PM, Andre Hora <andrehoraa(a)gmail.com> wrote:
Yes
Doru we should get two information:
the full graph.
the current selection and its dependent based on the full one.
would the sub model selection work? as current selection? I guess so.
Hello,
As I said in the previous email we have a filtered loader working ok where I
basically reused some classes. The implementation is based on a
importContext to filter the imported model.
However, I am not sure if it is the best implementation because we are using
a separated filter (the context) but the filter should be the meta-model
(i.e., we should use FMMetaRepositoryFilter, the same we did with the
filtered exporter). Like that I guess we can even remove the classes
FMImporterFilter and FMParseClientFilter.
So, Doru, to use our implemented FMMetaRepositoryFilter to export filtered
models, you remember that we needed to adapt the classes
FMRepositoryVisitor, FMRepository and FMMetaRepository.
Now, to import filtered models we need to adapt classes such as FMImporter.
I can have a look on that and let you know.
We do not want to touch the FMImporter. The whole point of the filter
is so that we can pass to the importer a sub-meta-model and then it
does the job out of the box. What we want is to translate the current
ImportingContext into the
data for the FMMetaRepositoryFilter. As a later step, we can remove
the internal model of the ImportingContext altogether and use instead
directly a meta-repository. The API of the importing context should
remain because it is used in the Smalltalk importer.
Doru if we have an object (FM related) that we can query the SmalltalkImporter could use
it
but we should keep the API.
May be the easiest thing to do in that case would be to move the importingContext closer
to the SmalltalkImporter.
What do you say?
Cheers,
Doru
What do you think?
regards,
On Wed, Nov 16, 2011 at 3:44 PM, Andre Hora <andrehoraa(a)gmail.com> wrote:
--
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
Hello Santiago,
You can find the custom loader Stef cited in: HoraExpTemp3 in SqueakSource
(load all the packages not related to Hismo). Then go to the Moose Panel and
click in "Import model from model from MSE file with context".
In fact I just fixed the wizard MooseImportFromMseWizard and used the
already implemented classes FMImporterFilter and FMParseClientFilter to
filter the model. The logic was already implemented.
regards,
So, the same idea we used to
On Mon, Nov 14, 2011 at 11:00 AM, Tudor Girba <tudor(a)tudorgirba.com>
wrote:
--
Andre Hora
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
On Mon, Nov 14, 2011 at 10:51 AM, Stéphane Ducasse
<stephane.ducasse(a)inria.fr> wrote:
>
> On Nov 14, 2011, at 7:59 AM, Tudor Girba wrote:
>
>> The consistency is achieved by having a filtering mechanism that works
>> based on the information from the meta-model. When you filter by saying that
>> you only want classes, the filter will produce a consistent but smaller
>> meta-model that will contain what is needed for the class to be
>> appropriately described.
>>
>> I think there is still one issue left in the algorithm, but first we
>> should see how it performs on larger case studies.
>>
>> In any case, one side-effect is that the information from the
>> ImportingContext should not be needed anymore because we could finally reuse
>> the one from the original meta-descriptions.
>
>
> Ok but then it means that you should have the dependencies expressed
> clearly at the meta model.
> and remove importingContext.
We have them in the form of property declared types. Furthermore, we also
take into account the derived information. So, if a property is derived, we
do not take it into account when computing the dependencies.
It works quite well. The only problem is that when the declared type is
generic we have to include in the dependencies all the subclasses. For
example, the type of inheritance superclass is Type, and this means that if
we want to load inheritances, we have to consider all entities that are
subclasses of Type (FAMIXClass, FAMIXTypeAlias ...).
This works well in almost all cases. The problem is with
annotationInstances which point to FAMIXEntity. So, currently, if you want
to load an annotation instance, you will end up loading the entire famix. I
guess we have to revisit the type of annotation instance to maybe be only a
named entity.
>
> Because having two mechanisms is not a good idea on the long term.
Exactly :).
Doru
>
> Stef
>>
>> Cheers,
>> Doru
>>
>>
>> On 13 Nov 2011, at 23:13, Stéphane Ducasse wrote:
>>
>>> I want to know in particular how the consistency of the resulting
>>> model is handled.
>>>
>>>
>>>> Thanks :).
>>>>
>>>> Andre, when you come back, we should pick up where we left and look
>>>> into the integration of the Fame filter in Moose.
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>>
>>>> On 13 Nov 2011, at 21:39, Nicolas Anquetil wrote:
>>>>
>>>>> FYI
>>>>>
>>>>> andre is on holiday till Wednesday
>>>>>
>>>>> nicolas
>>>>>
>>>>> ----- Mail original -----
>>>>>> De: "Tudor Girba" <tudor(a)tudorgirba.com>
>>>>>> À: "Moose-related development"
<moose-dev(a)iam.unibe.ch>
>>>>>> Envoyé: Dimanche 13 Novembre 2011 21:22:06
>>>>>> Objet: [Moose-dev] Re: Help with VerveineJ
>>>>>> +1.
>>>>>>
>>>>>> We now have the basic mechanism for loading partial models. But,
I
>>>>>> will let Andre answer more details.
>>>>>>
>>>>>> Andre, you have the floor :)
>>>>>>
>>>>>> Cheers,
>>>>>> Doru
>>>>>>
>>>>>>
>>>>>> On 13 Nov 2011, at 16:12, Stéphane Ducasse wrote:
>>>>>>
>>>>>>> If I remember Andre did a custom mse loader that can filter
>>>>>>> entities
>>>>>>> to be loaded.
>>>>>>> Now I will wait for his answer
>>>>>>>
>>>>>>> In general this is a good idea to extract at maximum level
and to
>>>>>>> filter while loading.
>>>>>>>
>>>>>>> Stef
>>>>>>>
>>>>>>> On Nov 11, 2011, at 7:43 PM, Santiago Vidal wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>> I had create several MSE files of different versions of a
Java
>>>>>>>> system using VerveineJ. Then, I had tried to load them to
the
>>>>>>>> Moose
>>>>>>>> Panel but after load two of them I run out of memory in
Moose
>>>>>>>> (The
>>>>>>>> Pharo error is "Space is Low").
>>>>>>>> I had the same problem when loading several versions of
Mondrian
>>>>>>>> to
>>>>>>>> Moose Panel. However, we solved it by using the following
script
>>>>>>>> (we select only those thing in which we are interested):
>>>>>>>>
>>>>>>>> | mooseModel packages task |
>>>>>>>>
>>>>>>>> #('2.10' '2.13' '2.100') do:
[:version |
>>>>>>>> | project |
>>>>>>>> project := (ConfigurationOfMondrian project version:
>>>>>>>> version).
>>>>>>>>
>>>>>>>> [
>>>>>>>> project load.
>>>>>>>>
>>>>>>>> "This is necessary by Moose to properly
import"
>>>>>>>> Gofer new
>>>>>>>> url:
>>>>>>>>
>>>>>>>>
'http://www.squeaksource.com/CollectionExtensions';
>>>>>>>> version:
>>>>>>>>
'CollectionExtensions-TudorGirba.29';
>>>>>>>> load.
>>>>>>>>
>>>>>>>> packages := (project packages collect: #name)
select:
>>>>>>>> [:p | p beginsWith: 'Mondrian'].
>>>>>>>> mooseModel := MooseModel new.
>>>>>>>> task := MooseSqueakClassCategoryImporterTask
new.
>>>>>>>> task importerClass: SmalltalkImporter.
>>>>>>>> task importingContext mergeClassAndMetaclass.
>>>>>>>> task model: mooseModel.
>>>>>>>> task runCandidateOperator.
>>>>>>>> task addFromPackagesNamed: packages.
>>>>>>>> task runWithProgress.
>>>>>>>>
>>>>>>>> mooseModel name: 'Mondrian ', version.
>>>>>>>> mooseModel allMethods do:
#numberOfLinesOfCode.
>>>>>>>> mooseModel install.
>>>>>>>> ] on: Error do: [ :ex | self halt. Transcript show:
'cannot
>>>>>>>> load version ', version, ' ', ex
printString. ].
>>>>>>>> ]
>>>>>>>>
>>>>>>>> Is there any way to do the same with VerveineJ (that is,
reduce
>>>>>>>> the
>>>>>>>> size of the MSE files)? Or is there a way to expand the
memory
>>>>>>>> of
>>>>>>>> Moose?
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> --
>>>>>>>> Santiago Vidal
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>
>>>>>> "One cannot do more than one can do."
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>> "In a world where everything is moving ever faster,
>>>> one might have better chances to win by moving slower."
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> "Presenting is storytelling."
>>
>>
>> _______________________________________________
>> 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
"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
--
Andre Hora
16 Nov
16 Nov
4:10 p.m.
Thanks!
Cheers
2011/11/16 Andre Hora <andrehoraa(a)gmail.com>
Hello Santiago,
You can find the custom loader Stef cited in: HoraExpTemp3 in SqueakSource
(load all the packages not related to Hismo). Then go to the Moose Panel
and click in "Import model from model from MSE file with context".
In fact I just fixed the wizard MooseImportFromMseWizard and used the
already implemented classes FMImporterFilter and FMParseClientFilter to
filter the model. The logic was already implemented.
regards,
So, the same idea we used to
On Mon, Nov 14, 2011 at 11:00 AM, Tudor Girba <tudor(a)tudorgirba.com>wrote;wrote:
--
Santiago Vidal
Hi,
On Mon, Nov 14, 2011 at 10:51 AM, Stéphane Ducasse <
stephane.ducasse(a)inria.fr> wrote:
--
Andre Hora
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Nov 14, 2011, at 7:59 AM, Tudor Girba wrote:
We have them in the form of property declared types. Furthermore, we also
take into account the derived information. So, if a property is derived, we
do not take it into account when computing the dependencies.
It works quite well. The only problem is that when the declared type is
generic we have to include in the dependencies all the subclasses. For
example, the type of inheritance superclass is Type, and this means that if
we want to load inheritances, we have to consider all entities that are
subclasses of Type (FAMIXClass, FAMIXTypeAlias ...).
This works well in almost all cases. The problem is with
annotationInstances which point to FAMIXEntity. So, currently, if you want
to load an annotation instance, you will end up loading the entire famix. I
guess we have to revisit the type of annotation instance to maybe be only a
named entity.
The consistency is achieved by having a filtering
mechanism that works
based on the information from the meta-model. When you filter
by saying
that you only want classes, the filter will produce a consistent but
smaller meta-model that will contain what is needed for the class to be
appropriately described.
I think there is still one issue left in the algorithm, but first we
should see
how it performs on larger case studies.
In any case, one side-effect is that the information from the
ImportingContext
should not be needed anymore because we could finally
reuse the one from the original meta-descriptions.
Ok but then it means that you should have the dependencies expressed
clearly at the meta model.
and remove importingContext.
Because having two mechanisms is not a good idea
on the long term.
Exactly :).
Doru
Stef
--
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
Cheers,
Doru
On 13 Nov 2011, at 23:13, Stéphane Ducasse wrote:
> I want to know in particular how the consistency of the resulting
model is
handled.
>
>
>> Thanks :).
>>
>> Andre, when you come back, we should pick up where we left and look
into
the integration of the Fame filter in Moose.
>>
>> Cheers,
>> Doru
>>
>>
>> On 13 Nov 2011, at 21:39, Nicolas Anquetil wrote:
>>
>>> FYI
>>>
>>> andre is on holiday till Wednesday
>>>
>>> nicolas
>>>
>>> ----- Mail original -----
>>>> De: "Tudor Girba" <tudor(a)tudorgirba.com>
>>>> À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
>>>> Envoyé: Dimanche 13 Novembre 2011 21:22:06
>>>> Objet: [Moose-dev] Re: Help with VerveineJ
>>>> +1.
>>>>
>>>> We now have the basic mechanism for loading partial models. But, I
>>>> will let Andre answer more details.
>>>>
>>>> Andre, you have the floor :)
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>>
>>>> On 13 Nov 2011, at 16:12, Stéphane Ducasse wrote:
>>>>
>>>>> If I remember Andre did a custom mse loader that can filter
entities
>>>>> to be loaded.
>>>>> Now I will wait for his answer
>>>>>
>>>>> In general this is a good idea to extract at maximum level and to
>>>>> filter while loading.
>>>>>
>>>>> Stef
>>>>>
>>>>> On Nov 11, 2011, at 7:43 PM, Santiago Vidal wrote:
>>>>>
>>>>>> Hi,
>>>>>> I had create several MSE files of different versions of a Java
>>>>>> system using VerveineJ. Then, I had tried to load them to the
Moose
>>>>>> Panel but after load two
of them I run out of memory in Moose
(The
>>>>>> Pharo error is
"Space is Low").
>>>>>> I had the same problem when loading several versions of Mondrian
to
>>>>>> Moose Panel. However, we
solved it by using the following script
>>>>>> (we select only those thing in which we are interested):
>>>>>>
>>>>>> | mooseModel packages task |
>>>>>>
>>>>>> #('2.10' '2.13' '2.100') do: [:version |
>>>>>> | project |
>>>>>> project := (ConfigurationOfMondrian project version:
>>>>>> version).
>>>>>>
>>>>>> [
>>>>>> project load.
>>>>>>
>>>>>> "This is necessary by Moose to properly
import"
>>>>>> Gofer new
>>>>>> url:
>>>>>> '
http://www.squeaksource.com/CollectionExtensions'#39;;
>>>>>>
version:
>>>>>> 'CollectionExtensions-TudorGirba.29';
>>>>>> load.
>>>>>>
>>>>>> packages := (project packages collect: #name) select:
>>>>>> [:p | p beginsWith: 'Mondrian'].
>>>>>> mooseModel := MooseModel new.
>>>>>> task := MooseSqueakClassCategoryImporterTask new.
>>>>>> task importerClass: SmalltalkImporter.
>>>>>> task importingContext mergeClassAndMetaclass.
>>>>>> task model: mooseModel.
>>>>>> task runCandidateOperator.
>>>>>> task addFromPackagesNamed: packages.
>>>>>> task runWithProgress.
>>>>>>
>>>>>> mooseModel name: 'Mondrian ', version.
>>>>>> mooseModel allMethods do: #numberOfLinesOfCode.
>>>>>> mooseModel install.
>>>>>> ] on: Error do: [ :ex | self halt. Transcript show:
'cannot
>>>>>> load version ', version, ' ', ex printString. ].
>>>>>> ]
>>>>>>
>>>>>> Is there any way to do the same with VerveineJ (that is, reduce
the
>>>>>> size of the MSE files)?
Or is there a way to expand the memory of
>>>>>> Moose?
>>>>>> Thanks
>>>>>>
>>>>>> --
>>>>>> Santiago Vidal
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>> "One cannot do more than one can do."
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> "In a world where everything is moving ever faster,
>> one might have better chances to win by moving slower."
>>
>>
>>
>>
>> _______________________________________________
>> 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
"Presenting is storytelling."
_______________________________________________
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
4784
days inactive
4790
days old
20 comments
6 participants
participants (6)
-
Alexandre Bergel -
Andre Hora -
Nicolas Anquetil -
Santiago Vidal -
Stéphane Ducasse -
Tudor Girba