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



--
Andre Hora