14 Nov
2011
14 Nov
'11
11 a.m.
Hi,
On Mon, Nov 14, 2011 at 10:51 AM, Stéphane Ducasse <
stephane.ducasse(a)inria.fr> wrote:
On Nov 14, 2011, at 7:59 AM, Tudor Girba wrote:
We have them in the form of property declared types. Furthermore, we also
take into account the derived information. So, if a property is derived, we
do not take it into account when computing the dependencies.
It works quite well. The only problem is that when the declared type is
generic we have to include in the dependencies all the subclasses. For
example, the type of inheritance superclass is Type, and this means that if
we want to load inheritances, we have to consider all entities that are
subclasses of Type (FAMIXClass, FAMIXTypeAlias ...).
This works well in almost all cases. The problem is with
annotationInstances which point to FAMIXEntity. So, currently, if you want
to load an annotation instance, you will end up loading the entire famix. I
guess we have to revisit the type of annotation instance to maybe be only a
named entity.
The consistency is achieved by having a filtering
mechanism that works
based on the information from the meta-model. When you filter
by saying
that you only want classes, the filter will produce a consistent but
smaller meta-model that will contain what is needed for the class to be
appropriately described.
I think there is still one issue left in the algorithm, but first we
should see
how it performs on larger case studies.
In any case, one side-effect is that the information from the
ImportingContext
should not be needed anymore because we could finally
reuse the one from the original meta-descriptions.
Ok but then it means that you should have the dependencies expressed
clearly at the meta model.
and remove importingContext.
Because having two mechanisms is not a good idea on
the long term.
Exactly :).
Doru
Stef
--
www.tudorgirba.com
"Presenting is storytelling."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
Cheers,
Doru
On 13 Nov 2011, at 23:13, Stéphane Ducasse wrote:
> I want to know in particular how the consistency of the resulting model
is
handled.
>
>
>> Thanks :).
>>
>> Andre, when you come back, we should pick up where we left and look
into
the integration of the Fame filter in Moose.
>>
>> Cheers,
>> Doru
>>
>>
>> On 13 Nov 2011, at 21:39, Nicolas Anquetil wrote:
>>
>>> FYI
>>>
>>> andre is on holiday till Wednesday
>>>
>>> nicolas
>>>
>>> ----- Mail original -----
>>>> De: "Tudor Girba" <tudor(a)tudorgirba.com>
>>>> À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
>>>> Envoyé: Dimanche 13 Novembre 2011 21:22:06
>>>> Objet: [Moose-dev] Re: Help with VerveineJ
>>>> +1.
>>>>
>>>> We now have the basic mechanism for loading partial models. But, I
>>>> will let Andre answer more details.
>>>>
>>>> Andre, you have the floor :)
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>>
>>>> On 13 Nov 2011, at 16:12, Stéphane Ducasse wrote:
>>>>
>>>>> If I remember Andre did a custom mse loader that can filter entities
>>>>> to be loaded.
>>>>> Now I will wait for his answer
>>>>>
>>>>> In general this is a good idea to extract at maximum level and to
>>>>> filter while loading.
>>>>>
>>>>> Stef
>>>>>
>>>>> On Nov 11, 2011, at 7:43 PM, Santiago Vidal wrote:
>>>>>
>>>>>> Hi,
>>>>>> I had create several MSE files of different versions of a Java
>>>>>> system using VerveineJ. Then, I had tried to load them to the
Moose
>>>>>> Panel but after load two of them I run out of memory in Moose
(The
>>>>>> Pharo error is "Space is Low").
>>>>>> I had the same problem when loading several versions of Mondrian
to
>>>>>> Moose Panel. However, we solved it by using the following script
>>>>>> (we select only those thing in which we are interested):
>>>>>>
>>>>>> | mooseModel packages task |
>>>>>>
>>>>>> #('2.10' '2.13' '2.100') do: [:version |
>>>>>> | project |
>>>>>> project := (ConfigurationOfMondrian project version:
>>>>>> version).
>>>>>>
>>>>>> [
>>>>>> project load.
>>>>>>
>>>>>> "This is necessary by Moose to properly
import"
>>>>>> Gofer new
>>>>>> url:
>>>>>> '
http://www.squeaksource.com/CollectionExtensions'#39;;
>>>> version:
>>>> 'CollectionExtensions-TudorGirba.29';
>>>> load.
>>>>
>>>> packages := (project packages collect: #name) select:
>>>> [:p | p beginsWith: 'Mondrian'].
>>>> mooseModel := MooseModel new.
>>>> task := MooseSqueakClassCategoryImporterTask new.
>>>> task importerClass: SmalltalkImporter.
>>>> task importingContext mergeClassAndMetaclass.
>>>> task model: mooseModel.
>>>> task runCandidateOperator.
>>>> task addFromPackagesNamed: packages.
>>>> task runWithProgress.
>>>>
>>>> mooseModel name: 'Mondrian ', version.
>>>> mooseModel allMethods do: #numberOfLinesOfCode.
>>>> mooseModel install.
>>>> ] on: Error do: [ :ex | self halt. Transcript show: 'cannot
>>>> load version ', version, ' ', ex printString. ].
>>>> ]
>>>>
>>>> Is there any way to do the same with VerveineJ (that is, reduce the
>>>> size of the MSE files)? Or is there a way to expand the memory of
>>>> Moose?
>>>> Thanks
>>>>
>>>> --
>>>> Santiago Vidal
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "One cannot do more than one can do."
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev