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
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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Yep, thanks Alexandre
Enviado desde mi iPad
El 11/11/2011, a las 20:06, Alexandre Bergel alexandre.bergel@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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi, 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@gmail.com À: "Moose-related development" moose-dev@iam.unibe.ch Cc: "Moose-related development" moose-dev@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@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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
+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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"One cannot do more than one can do."
FYI
andre is on holiday till Wednesday
nicolas
----- Mail original -----
De: "Tudor Girba" tudor@tudorgirba.com À: "Moose-related development" moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"One cannot do more than one can do."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Thanks for the answers! I will wait for Andre's answer Cheers Santiago
2011/11/13 Nicolas Anquetil nicolas.anquetil@inria.fr
FYI
andre is on holiday till Wednesday
nicolas
----- Mail original -----
De: "Tudor Girba" tudor@tudorgirba.com À: "Moose-related development" moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"One cannot do more than one can do."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@tudorgirba.com À: "Moose-related development" moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"One cannot do more than one can do."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
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@tudorgirba.com À: "Moose-related development" moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"One cannot do more than one can do."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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.
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@tudorgirba.com À: "Moose-related development" moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"One cannot do more than one can do."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Presenting is storytelling."
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.
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@tudorgirba.com À: "Moose-related development" moose-dev@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@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"One cannot do more than one can do."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Presenting is storytelling."
Moose-dev mailing list Moose-dev@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@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@tudorgirba.com À: "Moose-related development" moose-dev@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@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"One cannot do more than one can do."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Presenting is storytelling."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@tudorgirba.com wrote:
Hi,
On Mon, Nov 14, 2011 at 10:51 AM, Stéphane Ducasse < stephane.ducasse@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@tudorgirba.com > À: "Moose-related development" moose-dev@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@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "One cannot do more than one can do." > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Presenting is storytelling."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow"
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@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@tudorgirba.comwrote:
Hi,
On Mon, Nov 14, 2011 at 10:51 AM, Stéphane Ducasse < stephane.ducasse@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@tudorgirba.com >> À: "Moose-related development" moose-dev@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@iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "One cannot do more than one can do." >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Presenting is storytelling."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow"
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Andre Hora
Hi Andre,
On Wed, Nov 16, 2011 at 3:49 PM, Andre Hora andrehoraa@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@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@tudorgirba.com wrote:
Hi,
On Mon, Nov 14, 2011 at 10:51 AM, Stéphane Ducasse stephane.ducasse@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@tudorgirba.com >>> À: "Moose-related development" moose-dev@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@iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev@iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> >>> "One cannot do more than one can do." >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "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@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Presenting is storytelling."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com "Every thing has its own flow"
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Andre Hora
-- Andre Hora
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Wed, Nov 16, 2011 at 4:29 PM, Tudor Girba tudor@tudorgirba.com wrote:
Hi Andre,
On Wed, Nov 16, 2011 at 3:49 PM, Andre Hora andrehoraa@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.
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
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@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@tudorgirba.com wrote:
Hi,
On Mon, Nov 14, 2011 at 10:51 AM, Stéphane Ducasse stephane.ducasse@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@tudorgirba.com >>>> À: "Moose-related development" moose-dev@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@iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev@iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "One cannot do more than one can do." >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev@iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "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@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Presenting is storytelling."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com "Every thing has its own flow"
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Andre Hora
-- Andre Hora
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
On Wed, Nov 16, 2011 at 5:41 PM, Andre Hora andrehoraa@gmail.com wrote:
On Wed, Nov 16, 2011 at 4:29 PM, Tudor Girba tudor@tudorgirba.com wrote:
Hi Andre,
On Wed, Nov 16, 2011 at 3:49 PM, Andre Hora andrehoraa@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.
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. 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
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@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@tudorgirba.com wrote:
Hi,
On Mon, Nov 14, 2011 at 10:51 AM, Stéphane Ducasse stephane.ducasse@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@tudorgirba.com >>>>> À: "Moose-related development" moose-dev@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@iam.unibe.ch >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev@iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "One cannot do more than one can do." >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev@iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev@iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> >>> "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@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Presenting is storytelling." > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com "Every thing has its own flow"
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Andre Hora
-- Andre Hora
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Andre Hora
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Wed, Nov 16, 2011 at 5:48 PM, Tudor Girba tudor@tudorgirba.com wrote:
Hi,
On Wed, Nov 16, 2011 at 5:41 PM, Andre Hora andrehoraa@gmail.com wrote:
On Wed, Nov 16, 2011 at 4:29 PM, Tudor Girba tudor@tudorgirba.com
wrote:
Hi Andre,
On Wed, Nov 16, 2011 at 3:49 PM, Andre Hora andrehoraa@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.
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 :)
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
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@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@tudorgirba.com wrote:
Hi,
On Mon, Nov 14, 2011 at 10:51 AM, Stéphane Ducasse stephane.ducasse@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@tudorgirba.com > >>>>> À: "Moose-related development" moose-dev@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@iam.unibe.ch > >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Moose-dev mailing list > >>>>>> Moose-dev@iam.unibe.ch > >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>>>> > >>>>> -- > >>>>> www.tudorgirba.com > >>>>> > >>>>> "One cannot do more than one can do." > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Moose-dev mailing list > >>>>> Moose-dev@iam.unibe.ch > >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>>> > >>>> _______________________________________________ > >>>> Moose-dev mailing list > >>>> Moose-dev@iam.unibe.ch > >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>> > >>> -- > >>> www.tudorgirba.com > >>> > >>> "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@iam.unibe.ch > >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > >> > >> _______________________________________________ > >> Moose-dev mailing list > >> Moose-dev@iam.unibe.ch > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > -- > > www.tudorgirba.com > > > > "Presenting is storytelling." > > > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev@iam.unibe.ch > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com "Every thing has its own flow"
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Andre Hora
-- Andre Hora
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Andre Hora
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@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.
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.
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@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@tudorgirba.com wrote:
Hi,
On Mon, Nov 14, 2011 at 10:51 AM, Stéphane Ducasse stephane.ducasse@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@tudorgirba.com >>>> À: "Moose-related development" moose-dev@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@iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev@iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "One cannot do more than one can do." >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev@iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "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@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Presenting is storytelling."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com "Every thing has its own flow"
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Andre Hora
-- Andre Hora
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Thanks! Cheers
2011/11/16 Andre Hora andrehoraa@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@tudorgirba.comwrote:
Hi,
On Mon, Nov 14, 2011 at 10:51 AM, Stéphane Ducasse < stephane.ducasse@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@tudorgirba.com >> À: "Moose-related development" moose-dev@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@iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "One cannot do more than one can do." >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Presenting is storytelling."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow"
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Andre Hora
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Alexandre Bergel -
Andre Hora -
Nicolas Anquetil -
Santiago Vidal -
Stéphane Ducasse -
Tudor Girba